Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace EnvironmentDefined's data.image with new link type #258

Closed
magnusbaeck opened this issue Mar 30, 2021 · 0 comments · Fixed by #264
Closed

Replace EnvironmentDefined's data.image with new link type #258

magnusbaeck opened this issue Mar 30, 2021 · 0 comments · Fixed by #264
Assignees
Labels
protocol All protocol changes
Milestone

Comments

@magnusbaeck
Copy link
Member

Description

The data.image member of EiffelEnvironmentDefinedEvent is defined like this:

A string identifying e.g. a Docker image. While not a perfect description of an environment, in many cases it is both sufficient and conducive.

Since a Docker image (and other kinds of execution environment images like VMDK or AMI) can be described with artifacts it's not clear why this field was introduced instead of having a link to an ArtC describing the image. Maybe made more sense when artifacts were identified with GAVs?

I suggest this field should be deprecated and replaced with a new link type, perhaps IMAGE, with EiffelArtifactCreatedEvent as the sole possible target.

Motivation

This would allow much more useful Eiffel environment definitions since the execution environment could be specified with links between events instead of a somewhat ambiguous data field that requires the consumer to make additional queries to other systems in order to get back into the Eiffel domain.

Exemplification

Here's what a DAG could look like, allowing a graph traversal to list which OS packages that were installed in the execution environment where the artifact was produced:

image

Benefits

This would improve execution environment traceability within the Eiffel DAG.

Possible Drawbacks

None I can think of, except maybe that removing the data.image would be a backward incompatible change that could be disruptive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
protocol All protocol changes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant