docs(spec): artifactType in multi-platform index manifests #1696
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1696 +/- ##
==========================================
+ Coverage 85.09% 85.12% +0.03%
==========================================
Files 129 129
Lines 5762 5762
==========================================
+ Hits 4903 4905 +2
+ Misses 613 611 -2
Partials 246 246 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
b80a3a3 to
91aad60
Compare
320889a to
2f8694b
Compare
|
While referring back to earlier notes today as I prepare our documentation for OpenTofu, I was reminded that the descriptors in index manifests are also allowed to include the In particular, including a copy of the downstream annotations is a required part of the Referrers API, although it is optional in other contexts. I think the arguments I made in favor of copying OpenTofu in particular does not need annotations in the index and so I don't know if I would be able to also include support for that in my work over in #1700, but it seems like a backward-compatible extension that could be implemented in a subsequent PR if there were sufficient interest in that. |
I think this makes sense.
I agree, we can gather more scenarios from the community and maybe implement it in the next iteration if needed. |
2f8694b to
22d2b77
Compare
This extends the previously-accepted proposal with two additional features related to the artifactType manifest property: - Both of the "oras manifest index" subcommands support an --artifact-type option, similar to that used with "oras push" today, that directly specifies an "artifactType" value to include in the index manifest. - The descriptors for the child manifests automatically include an artifactType property matching that in the child manifest, if any. These extensions allow using ORAS to create index manifests for systems that use index-level artifactType to quickly reject artifacts that appear to be intended for use by other unrelated software, such as trying to use a multi-platform container image as an OpenTofu provider plugin. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The previous commit introduced some additional features to help support multi-platform artifacts that are not container images. This commit adjusts terminology used elsewhere in the document to more clearly reflect that expanded scope. The sections that specifically discuss container images retain the existing "multi-arch image" terminology, but the sections describing the more general concept instead now prefer the more general term "multi-platform artifact". Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
22d2b77 to
eb24638
Compare
…ect#1696) Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This extends the previously-accepted proposal with two additional features related to the artifactType manifest property:
oras manifest indexsubcommands support an--artifact-typeoption, similar to that used withoras pushtoday, that directly specifies anartifactTypevalue to include in the index manifest.artifactTypeproperty matching that in the child manifest, if any.These extensions allow using ORAS to create index manifests for systems that use index-level
artifactTypeto quickly reject artifacts that appear to be intended for use by other unrelated software, such as trying to use a multi-platform container image as an OpenTofu provider plugin.In order to describe the proposal comprehensively I've added a new section describing what values these commands write into each of the properties of the generated index manifests. Since there was previously no direct documentation of that, this changeset also retroactively documents some behavior resulting from the original proposal that is not directly related to the treatment of
artifactType. I tried to make that correctly reflect the behavior in the current experimental implementation, but of course I would be happy to correct any errors I've made.What this PR does / why we need it: This proposal change aims to formalize what was previously discussed in #1670.
There are no code changes in this pull request.
I am contributing this change on behalf of the OpenTofu project.