Docker builds are not slow if you do them properly 1. Add layers properly, so th...

jacobwg · on Feb 23, 2023

This is good advice!

> Use Docker layer caching on GitHub Actions or your favorite CI (https://evilmartians.com/chronicles/build-images-on-github-a...)

Since the time that article was written, BuildKit added native support for interacting with the GitHub Actions cache, so it's even easier than they describe:

    - uses: docker/build-push-action@v4
      with:
        cache-from: type=gha
        cache-to: type=gha,mode=max

Kyle actually wrote a blog post with more details if you're interested: https://depot.dev/blog/docker-layer-caching-in-github-action...

What has to happen with cache-to and cache-from is BuildKit has to create cache tarball files for each of the layers to be cached, then upload them to the remote cache destination. Then next build when there's a cache match, BuildKit downloads the tarballs from the remote store and un-tars them so that it can continue the build.

This process can be slow, from creating the tarballs, to transferring them over the network, to unpacking them again. This is one of the reasons we created Depot in the first place. We had several commercial projects with highly optimized Dockerfiles, where saving and loading cache to GitHub Actions took several minutes, representing a significant amount of the overall build time. We also wanted to use some more advanced Dockerfile features like `RUN --mount=type=cache` that are entirely unsupported in GitHub Actions.

With Depot, builds re-use the same persistent SSD, so you get perfectly incremental performance, similar to the speed you'd get on a local machine, without any network transfers. So if you put effort into optimizing Dockerfiles as you describe, you actually get to keep all that time savings. Our app backend's CI Docker builds usually complete in about 20 seconds for instance.

> hadolint is a good docker linter but there is no tool in the market that helps people optimize docker images

We're just getting started on this, but we'd like to provide insights like this through Depot, since we control the build execution environment and can observe what happens inside the build.