3 ms·

Dagger is Apache 2, no signup required: https://github.com/dagger/dagger#readme https://github.com/dagger/dagger#readme I struggle to think of what I would nee

Dagger is Apache 2, no signup required: https://github.com/dagger/dagger#readme https://github.com/dagger/dagger#readme I struggle to think of what I would need a SaaS service to run BuildKit for me unless they're trying to take on GitHub Actions's compute side or whatever

jacobwg 4y ago
I think we are trying to take on GitHub Actions' compute side yeah — you'd want to either self-host your own BuildKit or use something like Depot for two major reasons: 1. Several of BuildKit's caching features either require or work best with a local disk. For instance things like `RUN --mount=type=cache` need a persistent disk, which Actions doesn't provide. You can also hit bottlenecks with saving and loading tarball cache from Actions (e.g. cache-from / cache-to) where it takes longer to download and unpack the tarballs compared to omitting the cache. Having a persistent disk makes all this "instant". 2. If you need to build images for ARM CPUs, QEMU in GitHub Actions is really slow. And if you want to build multi-platform images natively (e.g. --platform linux/amd64,linux/arm64), BuildKit needs a simultaneous connection to two native builders. Depot automates all that (it will launch two VMs at once and connect them to the build). GitHub Actions today also only offers 2 CPUs for the build - they're launching a beta of larger machine sizes currently.
verdverm 4y ago
Dagger is helping companies scale BuildKit in a self-hosted setup (that I am aware of). Not sure about the Dagger + GHA self-hosted runner story, one would assume it would be a natural extension of their general self-hosted BuildKit, just point Dagger at whatever BuildKit domain/ip you are using. Dagger is open-source, but also has paid things if you talk to them. They are very focused on a few key users in their paid plans, rather than opening the floodgates, as I understand it.

jacobwg 4y ago

I think we are trying to take on GitHub Actions' compute side yeah — you'd want to either self-host your own BuildKit or use something like Depot for two major reasons: 1. Several of BuildKit's caching features either require or work best with a local disk. For instance things like `RUN --mount=type=cache` need a persistent disk, which Actions doesn't provide. You can also hit bottlenecks with saving and loading tarball cache from Actions (e.g. cache-from / cache-to) where it takes longer to download and unpack the tarballs compared to omitting the cache. Having a persistent disk makes all this "instant". 2. If you need to build images for ARM CPUs, QEMU in GitHub Actions is really slow. And if you want to build multi-platform images natively (e.g. --platform linux/amd64,linux/arm64), BuildKit needs a simultaneous connection to two native builders. Depot automates all that (it will launch two VMs at once and connect them to the build). GitHub Actions today also only offers 2 CPUs for the build - they're launching a beta of larger machine sizes currently.

verdverm 4y ago

Dagger is helping companies scale BuildKit in a self-hosted setup (that I am aware of). Not sure about the Dagger + GHA self-hosted runner story, one would assume it would be a natural extension of their general self-hosted BuildKit, just point Dagger at whatever BuildKit domain/ip you are using. Dagger is open-source, but also has paid things if you talk to them. They are very focused on a few key users in their paid plans, rather than opening the floodgates, as I understand it.