3 ms·
I just added creating and publishing ARM64 docker containers to our automated release process and the CI (GitHub Actions) time went from about 10 minutes to an
by davidmurdoch 4y ago
I just added creating and publishing ARM64 docker containers to our automated release process and the CI (GitHub Actions) time went from about 10 minutes to an hour and half.
I don't expect many teams to volunteer to suffer this sort of slowdown and complexity in the near term.
- jacobwg 4y agoI've been working on Depot (https://depot.dev https://depot.dev) specifically for this reason: it's a hosted Docker builder service that runs BuildKit on managed VMs. When it receives incoming build requests, it routes them to a VM running the target architecture, x86 VMs run in Fly.io, arm64 VMs run in AWS. Since it's all BuildKit, you can swap `docker buildx build` for `depot build` and it works exactly the same - I made a depot/build-push-action to drop in place of the docker/build-push-action in GitHub Actions. It also has a persistent SSD cache disk for each builder, that was my other pain with GitHub Actions, time saving and loading layer cache was negating the speedups from cache hits - with a persistent disk, there's no saving or loading. Anyways, combo of having a local cache and running on real ARM machines gives like an order of magnitude speedup to builds compared to the QEMU emulation. Still a new project, not yet officially launched, and hosted services aren't for everyone, but exactly as you said, the status quo is amazingly painful.
- andreineculau 4y agoThat's because there are no arm runners on GitHub actions. So you now emulate arm, thus slow. You can add hosted arm GitHub runners or register arm hosts for docker and see down to earth build times.