There should be a much less complex workflow and set of actions for using multiple runners to build multi-arch images

[spkane]

At the moment, it is much too complex to use multiple runners when building multi-arch images.

My workflow is pretty clean when I just use buildx to build all the platforms, but it is also way too slow due to the QEMU emulation. Using multiple runners of the correct platform/arch is MUCH faster, but the workflow is a mess and, the resulting manifest is not ideal.

It would be great if there was an action that was designed to intelligently and cleanly merge multiple manifests. Most of my images have many tags on them from the docker/metadata-action action, and merging all of those is painful.

It seems like this workflow is likely to become more and more common with the introduction of arm64 runners. In the meantime, if anyone has a workflow they are really happy with sharing it here would be great.

At the moment, my flow uses: these actions:

• actions/checkout@v4
• actions-tools/[email protected]
• docker/metadata-action@v5
• docker/setup-buildx-action@v3
• docker/login-action@v3
• docker/build-push-action@v5
• Noelware/docker-manifest-action@master

There is a lot of duplication for each architecture in the current flow, and the assembly of the final manifest only handles the latest tag at the moment, even though there are a lot more defined in the metadata action for each platform.

[crazy-max]

Thanks for your feedback. We currently have this documentation to show how to distribute builds across runners: https://docs.docker.com/build/ci/github-actions/multi-platform/#distribute-build-across-multiple-runners but we we plan to ease this kind of integration in the future.

[spkane]

Yeah, I looked at that documentation a bit, but it seemed to really only cover the most straightforward workflow. If you use docker/metadata-action@v5 extensively, merging all those tags seems trickier. Now that I have something that is basically working though, I'll re-read it and see if I can re-work things a bit to maintain my annotations, etc.

Anyhow, I'm glad to hear there are plans to make this easier in the future.

UPDATED: I do see that you can use the docker/metadata-action@v5 again in the merge step, so I will give that a try and see if that helps for my use case. Thanks!

[spkane]

@crazy-max One thing that might be nice with the current documentation is a lot more workflow comments describing what each step is doing and why. Although I have it figured out now, explaining things like why the first two metadata actions only define images and no tags would be very helpful when you are trying to modify the basic flow as documented to work inside an existing or more complicated workflow that is being used in a real-world environment.