Add artifactType to image index #1066
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AaronFriel
requested review from
jonjohnsonjr,
jonboulle,
stevvooe,
sudo-bmitch,
sajayantony,
tianon,
vbatts and
cyphar
as code owners
AaronFriel
force-pushed
the
friel/artifact-index
branch
from
45d6dc3
to
136f1bb
Compare
|
(#1020 is also very related 👀) |
It would be useful for implementations which generate multiple artifacts, each with their own platform or other metadata and perhaps, associated signatures, attestations, to be able to index them all in a single image index. As an implementer, I'm considering having a top level "package" stored as an image index, which then references all the artifacts in the package as artifacts (image manifests). The artifactType of the image index would be "application/...package", and the artifactType of the image manifests could be: * "application/...plugin" with annotations and/or platform fields set to indicate that it is the plugin for, e.g., macOS with Apple Silicon (darwin-arm64) * "application/...schema" with annotations indicating this is a separate artifact * ... other artifact types as needed Using an image index in this use case is helpful as we would want to associate SBOMs, signatures to the individual artifacts references, so that a client only needs to download and verify the artifacts it consumes selects from the index. Signed-off-by: Aaron Friel <mayreply@aaronfriel.com>
AaronFriel
force-pushed
the
friel/artifact-index
branch
from
136f1bb
to
749ea9a
Compare
sajayantony
approved these changes
Jun 9, 2023
There was a problem hiding this comment.
This aligns with #1020 and defines these fields that can be used by artifact authors. These are optional fields and having them enables distribution spec to return indexes that may be referrers to other artifacts.
|
Need to update the json schema and the go-specs. I can do that up as follow up PR. |
This was referenced Jun 15, 2023
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It would be useful for implementations which generate multiple artifacts, each with their own platform or other metadata and perhaps, associated signatures, attestations, to be able to index them all in a single image index.
As an implementer, I'm considering having a top level "package" stored as an image index, which then references all the artifacts in the package as artifacts (image manifests). The artifactType of the image index would be "application/...package", and the artifactType of the image manifests could be:
Using an image index in this use case is helpful as we would want to associate SBOMs, signatures to the individual artifacts references, so that a client only needs to download and verify the artifacts it consumes selects from the index.