Merge the ARM Docker images into the existing images (multi-platform images)

[mnapoli]

See https://github.com/brefphp/bref/issues/1043#issuecomment-1462675792 and the discussion.

[mnapoli]

This is more complex than I anticipated. Currently blocked on this: https://github.com/docker/buildx/issues/59#issuecomment-616061869

What this issue means is that it's impossible/hard to build multi-platform images locally, then run tests/export layers, then push to Docker Hub. Currently multi-platform images MUST be pushed immediately to Docker Hub.

I will revert to separate images for the Bref v2.0 release, and will later work on unifying them.

[shouze]

@mnapoli you also have the option to use docker manifest create.

An example: https://stackoverflow.com/a/70306574

So the idea would be to keep building separately tagged images (eg php-82-x86, php-82-arm64). Then triggering a manifest create workflow dispatch at the end of any build workflow of a given arch.

The manifest create workflow should be able to gently fail depending of the builds race condition. But when it is triggered at the time you have all archs images built & tagged, then you're ready to merge then thanks to docker manifest create command and then push them.

Final note: in fact when you trigger the manifest create github action workflow, best option is to pass docker image couple of unique hashs, not named tags.

[mnapoli]

Thanks!

On a side note: https://docs.aws.amazon.com/lambda/latest/dg/images-create.html#images-reqs

Lambda provides multi-architecture base images. However, the image you build for your function must target only one of the architectures. Lambda does not support functions that use multi-architecture container images.

Do you think that will be an issue for users? I'm thinking that users that deploy using Docker will re-build their images anyway, but I'm not 100% sure they won't be impacted 🤔

[shouze]

Well, yes users will build their own image when deploying docker image so the image they will build will be mono arch by default (because new image build means new docker manifest from scratch).

[mnapoli]

Awesome thanks for confirming.

[mnapoli]

Spent some more time on this. From my understanding Depot doesn't have the problem (only Docker buildx does).

Here are some options I've identified

• dig into docker manifest -> if I can avoid it, I'd prefer, that's introducing yet another concept and another step, adding complexity
• build platforms separately, then run tests, then build + push together (cache will be reused)
  • In CI for tests, we could run tests just like on master, i.e. separate platforms
  • In CI for releasing, we are using Depot, so we could build multiple platforms at once (we could also skip running tests and instead have a dependency on the "tests" workflow)
  • Locally, we could have an error printed if trying to build without CPU=xxx (when not using Depot)

I need to spend a lot more time on this, for those following this issue don't expect a speedy resolution (unless your company can sponsor that work 😬)