4 Commits

Author SHA1 Message Date
Nicolas De Loof
c3a0c35681 implement extends.file replace without yqlib
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
2025-03-11 14:18:41 +01:00
Nicolas De Loof
66a47169d5 Publish compose file with required siblings used by extends
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
2025-03-07 13:58:10 +01:00
Milas Bowman
7c8ff36d78 move around OCI logic, auto fallback/retry 1.1 -> 1.0
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
2023-12-05 18:08:38 +01:00
Milas Bowman
111ad3b039 fix(publish): add OCI 1.0 fallback support for AWS ECR
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.

Signed-off-by: Milas Bowman <milas.bowman@docker.com>
2023-12-05 18:08:38 +01:00