2 ms·
Congratulations on the launch. I am currently using GitHub actions and docker/setup-qemu-action@master. Then just call docker buildx with the platform arg. This
by nodesocket 4y ago
Congratulations on the launch. I am currently using GitHub actions and docker/setup-qemu-action@master. Then just call docker buildx with the platform arg. This works, except the builds do take a while since it’s running on Intel emulated arm64 (Microsoft booo).
What happens when GitHub adds native arm support though? Seems like a big value add of your service is immediately displaced and additionally can use self-hosted runners with GitHub to solve caching.
- jacobwg 4y ago> What happens when GitHub adds native arm support though? That will make it much faster to build arm images on GHA natively - in that scenario, Depot should still be several times faster like we are on Intel today, primarily due to how we're managing layer cache to avoid needing to save it or load it between builds (cache-to / cache-from), as well as just having larger runners and more sophisticated orchestration. We can take advantage of BuildKit's ability to share cache and deduplicate steps between concurrent builds for instance. We're also expanding Depot in a few different directions, including along the security path with container signing and SBOM support, as well as some upcoming build insights and analytics features. The goal is that it's always super easy to `depot build` from wherever you `docker build` today, and that Depot provides the best possible experience for container builds.