build-push-action

Yes but one image push for us is >10GB, due to ML dependencies. And even if it is intelligent and supports per layer caching, you can’t share between release branches - https://github.com/docker/build-push-action/issues/862. And even if that did work, I’ve found it much more reliable to use the actual docker BuildX disk state than to try and get caching for complex multi stage builds working reliably. I have a case right now where there’s no combination of —cache-to/from flags that will give me a 100% cached rebuild starting from a fresh builder, using only remote cache. I should probably report it to the Docker team, but I don’t have a minimal repro right now and there’s a 10% chance it’s actually my fault.

Does build-push-action solve this? I haven’t used their multi-arch configs but I was under the impression that it was pretty smooth. https://github.com/docker/build-push-action

I previously tried to use Docker `docker/setup-qemu-action@v2` and `docker/setup-buildx-action@v2` for this purpose (see that example https://github.com/docker/build-push-action#git-context). Thanks to buildkit, platform switching works transparently. However, building on ARM via QEMU on GitHub Actions is terribly slow (something like 5 times more), which is hard to accept. Therefore, full of hope, I am waiting for GitHub Actions to make cloud runners available on ARM, because it is a blocker for the implementation of Graviton on the AWS environment for us. For a while, the blocker in GitHub Actions for providing ARM support was that Azure doesn't have ARM support. In this way, the Azure cloud offering may determine the habits of AWS consumers.