Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cache is King: A guide for Docker layer caching in GitHub Actions

blacksmith.sh

Post reply on HN
Print view View original

51–60 of 111 posts

Re: Cache is King: A guide for Docker layer caching in GitHub Actions

#51

Post by ValtteriL »

remdoWater wrote: post #33
ValtteriL wrote: post #31

Docker layer caching is one of the reasons I moved to Jenkins 2 years ago and have been very happy with it for the most part. I only need to install utils once and all build time goes to building my software. It even integrates nicely with Github. Result: 50% faster feedback. However, it needs a bit initial housekeeping and discipline to use correctly. For example using Jenkinsfiles is a must and using containers as…

what do you mean by discipline here?

Basically using exclusively declarative pipelines with Jenkinsfiles in SCM, avoiding cluttering Jenkins with tools aside from docker, keeping Jenkins up to date and protected with proper auth.

Jenkins is the most flexible automation platform and its easy to do things in suboptimal ways (eg. Configuring jobs using the GUI).

There's also a way to configure Jenkins the IaC way and I am hoping to dig into that at some point. The old way requires manual work that instictly feels wrong when automating everything else.

Re: Cache is King: A guide for Docker layer caching in GitHub Actions

#52

Post by 20thr »

teaearlgraycold wrote: post #18
boronine wrote: post #13

I've spent days trying all of these solution at my company. All of these solutions suck, they are slow and only successful builds get their layers cached. This is a dead end. The only workable solution is to have a self-hosted runner with a big disk.

I use namespace’s action runners for this (just a customer, not affiliated in any way). They’re a company with a pretty good product stack. Although the web UI is annoyingly barebones.

Hi -- Namespace's CEO here; if you have a chance, please drop me a note at hugo-at-namespacelabs.com; I'd love to hear what we could be doing better in the UI, and product overall. Thank you!

Hugo @ Namespace (https://namespace.so)

Re: Cache is King: A guide for Docker layer caching in GitHub Actions

#53

Post by mshekow »

I took a detailed look at Docker's caching mechanism (actually: BuildKit) in this article https://www.augmentedmind.de/2023/11/19/advanced-buildkit-ca...

There I also explain that IF you use a registry cache import/export, you should use the same registry to which you are also pushing your actual image, and use the "image-manifest=true" option (especially if you are targeting GHCR - on DockerHub "image-manifest=true" would not be necessary).

Re: Cache is King: A guide for Docker layer caching in GitHub Actions

#54

Post by mhitza »

solatic wrote: post #20

As someone who spent way too much time chasing this rabbit, the real answer is Just Don't. GitHub Actions is a CI system that makes it easy to get started with simple CI needs but runs into hard problems as soon as you have more advanced needs. Docker caching is one of those advanced needs. If you have non-trivial Docker builds then you simply need on-disk local caching, period. Either use Depot or switch to self-hos…

On one project that was a bit more involved, I pulled the latest image I've built from the registry before starting the build. That worked well enough for caching in my case.

Re: Cache is King: A guide for Docker layer caching in GitHub Actions

#55

Post by ithkuil »

solatic wrote: post #20

As someone who spent way too much time chasing this rabbit, the real answer is Just Don't. GitHub Actions is a CI system that makes it easy to get started with simple CI needs but runs into hard problems as soon as you have more advanced needs. Docker caching is one of those advanced needs. If you have non-trivial Docker builds then you simply need on-disk local caching, period. Either use Depot or switch to self-hos…

Huge shout-out to depot! It works really well!

Re: Cache is King: A guide for Docker layer caching in GitHub Actions

#56

Post by cqqxo4zV46cp »

solatic wrote: post #20

As someone who spent way too much time chasing this rabbit, the real answer is Just Don't. GitHub Actions is a CI system that makes it easy to get started with simple CI needs but runs into hard problems as soon as you have more advanced needs. Docker caching is one of those advanced needs. If you have non-trivial Docker builds then you simply need on-disk local caching, period. Either use Depot or switch to self-hos…

I got it working, with intermediate layers, too. All to find that I didn’t see that material a performance benefit after taking into account how long it takes to pull from and push to the cache.

Re: Cache is King: A guide for Docker layer caching in GitHub Actions

#57

Post by pas »

bushbaba wrote: post #38
solatic wrote: post #20

As someone who spent way too much time chasing this rabbit, the real answer is Just Don't. GitHub Actions is a CI system that makes it easy to get started with simple CI needs but runs into hard problems as soon as you have more advanced needs. Docker caching is one of those advanced needs. If you have non-trivial Docker builds then you simply need on-disk local caching, period. Either use Depot or switch to self-hos…

Can’t you use s3 + mountpoint for most distributed CI cache needs?

if you want fast builds it's worth spinning up a buildkit server on a beefy dedicated server.

docker/nerdctl only transfers the context, everything else is cached on the builder. it's very useful for monorepos (where you usually want to build and tag images for every tested commit)

and the builder directly pushes the images/tags/layers to the registry. (which can be just a new tag for already existing layer.)

a noop job is about 2 sec on GitLab CI this way.

Re: Cache is King: A guide for Docker layer caching in GitHub Actions

#58

Post by dindresto »

jpgvm wrote: post #44

The trick to Docker (well OCI) images is never under any circumstance use `docker build` or anything based on it. Dockerfile is your enemy. Use tools like Bazel + rules_oci or Gradle + jib and never spend time thinking about image builds taking time at all.

+1 to this, migrating our build setup to Nix + nix2container decreased our pipeline duration for incremental changes by a lot, thanks to Nix's granular caching abilities.

Re: Cache is King: A guide for Docker layer caching in GitHub Actions

#60

Post by omeid2 »

tkiolp4 wrote: post #59

Docker has been among us for years. Why isn’t efficient caching already implemented out of the box? It’s a leaking abstraction that users have to deal with. Annoying at best.

Efficient caching exists when caching makes sense, layers are meaningfully cached.

What most people need but don't use is base layers that are upstream of their code repo and released regularly, not at each commit.

Containerisation has made reproducible environments so easy that people want to reproduce it at each CI run, a bit too much.

Post reply on HN