Multi-arch Builds to inherit Name/Image from parameter

[driverpt]

As title says:

e.g.:

docker buildx build --platform linux/arm64,linux/amd64 -t foo:sometag -f ./Dockerfile .

And the result should be:

foo:sometag (Manifest List)
foo:sometag-arm64 (Manifest)
foo:sometag-amd64 (Manifest)

Currently the Actual Images (arm64 and amd64) are untagged

[crazy-max]

docker buildx build --platform linux/arm64,linux/amd64 -t foo:sometag -f ./Dockerfile .

Yes this will build a manifest-list image tagged foo:sometag.

And the result should be:

foo:sometag (Manifest List)
foo:sometag-arm64 (Manifest)
foo:sometag-amd64 (Manifest)

I don't see in which use case you want a tag per arch, but you can use:

docker buildx build --platform linux/arm64 -t foo:sometag-arm64 -f ./Dockerfile .
docker buildx build --platform linux/amd64 -t foo:sometag-amd64 -f ./Dockerfile .

Edit:

Oh ok you want tag generated for each platform. That's not how it works and don't think that's something we are going to support as it's the old-fashioned way that was used with docker manifest. What's your use case?

[driverpt]

@crazy-max , in Amazon Elastic Container Registry you can define Lifecycle Policy based on Tags and Tag prefixes. If we only add a Tag to the Manifest List and not the Manifests, it will be automatically deleted, so we wanted to propagate the Tag from the Manifest List to the "arch" images.

You can check an example on how Amazon versions the Corretto Container

Source

[crazy-max]

You can check an example on how Amazon versions the Corretto Container

If your policy is based on tags and tag prefixes then it's fine to only rely on manifest list imo. Why bother with duplicated manifest for each arch when a manifest list is enough? Did I miss something?

[driverpt]

If we rely solely on manifest list, that means that non-tagged Manifests/Images will be deleted by the Lifecycle policy. If we promote a manifest list to a certain environment, e.g.: Staging we need to tag all, otherwise ECR will remove them (while keeping the manifest list)

[tonistiigi]

If we rely solely on manifest list, that means that non-tagged Manifests/Images will be deleted by the Lifecycle policy. If we promote a manifest list to a certain environment, e.g.: Staging we need to tag all, otherwise ECR will remove them (while keeping the manifest list)

I'm pretty sure that is not the case. It would be ECR bug if that would be the case. If manifest list is tagged and points to a manifest that should mean that manifest also has a reference and is not released before the manifest list is. @samuelkarp

[driverpt]

It's pretty easy to reproduce:

1. Create ECR Repo
2. Add Lifecycle Policy Rule to only maintain 0 Untagged Images
3. Push something using docker buildx build.....

You can use the Lifecycle Policy Rule Tester in AWS Console

[driverpt]

Any updates on this folks? @samuelkarp @tonistiigi @crazy-max

[samuelkarp]

Hi @driverpt,

I've reached out to my colleagues on the ECR team. It looks like you're seeing a bug in the rule tester, but those images will not be deleted. @tonistiigi's explanation of the logic ("If manifest list is tagged and points to a manifest that should mean that manifest also has a reference and is not released before the manifest list is.") is correct.

Thanks!
Sam

[crazy-max]

Thanks @samuelkarp for your feedback!

[driverpt]

Thanks folks. @samuelkarp @tonistiigi @crazy-max