You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently ORAS CLI causes artifact manifest with auto fallback to image manifest. As per recent discussions in OCI https://hackmd.io/moB5-fsQTbGmDpnrsY-4yg we feel that auto conversion of manifests leads to different digests that clients may produce.
Why is this needed for ORAS?
If a registry starts supporting the artifact manifest, then ORAS CLI would start pushing the new manifest type which might potentially break downstream consumers who might know now about the this manifest type. This makes the pipeline fragile.
One option would be to make the default use --v1.1 and fail on push. And the clients can then specify --v1.0 which would only use the image manifest and continue using image manifest throughout its time until the producer chooses to push the new type.
Currrently this behavior switch depends on the target registry and moving this control to the client is the main ask here.
Are you willing to submit PRs to contribute to this feature?
Yes, I am willing to implement it.
The text was updated successfully, but these errors were encountered:
As discussed in the community call, the flag --image-spec will be the default to v1.1-image and the auto fallback will be removed. No new flags or flag values will be added.
What is the version of your ORAS CLI
0.16.0
What would you like to be added?
Currently ORAS CLI causes artifact manifest with auto fallback to image manifest. As per recent discussions in OCI https://hackmd.io/moB5-fsQTbGmDpnrsY-4yg we feel that auto conversion of manifests leads to different digests that clients may produce.
Why is this needed for ORAS?
If a registry starts supporting the artifact manifest, then ORAS CLI would start pushing the new manifest type which might potentially break downstream consumers who might know now about the this manifest type. This makes the pipeline fragile.
One option would be to make the default use --v1.1 and fail on push. And the clients can then specify --v1.0 which would only use the image manifest and continue using image manifest throughout its time until the producer chooses to push the new type.
Currrently this behavior switch depends on the target registry and moving this control to the client is the main ask here.
Are you willing to submit PRs to contribute to this feature?
The text was updated successfully, but these errors were encountered: