fix(publish): add OCI 1.0 fallback support for AWS ECR

[milas]

What I did
Currently, we publish Compose artifacts following the OCI 1.1 specification, which is still in the RC state.

As a result, not all registries support it yet. Most notably, AWS ECR will reject certain OCI 1.1-compliant requests with 405 Method Not Supported with cryptic Invalid JSON errors.

This adds initial support for Compose to generate either an OCI 1.0 or OCI 1.1 compatible manifest. Notably, the OCI 1.0 manifest will be missing the application/vnd.docker.compose.project artifact type, as that does not exist in that version of the spec. (Less importantly, it uses an empty ImageConfig instead of the newer application/vnd.oci.empty.v1+json media type for the config.)

Currently, this is not exposed as an option (via CLI flags or env vars). By default, OCI 1.1 is used unless the registry domain is amazonaws.com, which indicates an ECR registry, so Compose will instead use OCI 1.0.

Moving forward, we should decide how much we want to expose/ support different OCI versions and investigate if there's a more generic way to feature probe the registry to avoid maintaining a hardcoded list of domains, which is both tedious and insufficient.

Related issue
https://docker.atlassian.net/browse/ENV-344

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[milas]

fyi I want to add an E2E test for this but need to get an ECR registry set up with permissions for GHA to use so will likely do that as a follow-up PR

[ndeloof]

I don't think we should hide lack of OCI 1.1 support on ECR, better have an command line flag to select OCI spec level to be applied. This also will allow users to deploy on registries we haven't tested and control OCI spec version being used.

[codecov]

Codecov Report

Attention: 117 lines in your changes are missing coverage. Please review.

Comparison is base (8026d0e) 56.88% compared to head (b6437d0) 56.56%.

❗ Current head b6437d0 differs from pull request most recent head d1f9ea3. Consider uploading reports for the commit d1f9ea3 to get more accurate results

Files	Patch %	Lines
internal/ocipush/push.go	0.00%	101 Missing ⚠️
pkg/compose/publish.go	0.00%	15 Missing ⚠️
cmd/compose/publish.go	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #11239      +/-   ##
==========================================
- Coverage   56.88%   56.56%   -0.32%     
==========================================
  Files         133      134       +1     
  Lines       11513    11553      +40     
==========================================
- Hits         6549     6535      -14     
- Misses       4326     4376      +50     
- Partials      638      642       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ndeloof]

would it make sense we:

• offer a flag to select OCI spec version to be used
• if not set, first try to publish as OCI 1.1, then on failure warn user and have a second try as OCI 1.0

[glours]

Sounds good to me, maybe a typo to fix first

[ndeloof]

LGTM but helper message should refer to OCI artifact spec, not image spec

[ndeloof]

OCI artifact specification

[milas]

OCI artifacts are dead, long live OCI images: https://github.com/opencontainers/image-spec/blob/main/manifest.md#guidelines-for-artifact-usage

😬

[ndeloof]

really? So this is an non-secret plan to make all this think damn confusing as an "image" can now either be an image or an arbitrary artifact 🥸

[milas]

I changed this to say "OCI Image/Artifact specification" - does that sound OK?

[also asked internally in Slack if anyone knows what the suggested nomenclature is 🤷🏻]

[milas]

fyi my latest push also includes a slight change: 4264d53

there's comments and references to the OCI spec there, but now using a custom media type for the config descriptor in OCI 1.0 style pushes so that the manifest is still identifiable as a Compose project - that's the suggested fall back in the spec