I’ve been creating some rather convoluted ways to try and make the best use of the build cache that I can. The thing is, I’ve never been very happy with them. So today I was reviewing the docs on the topic to see if I could find a better way to do things.
I hadn’t heard of, or maybe just skimmed over, the --mount=type=cache RUN cache option before, so I thought I’d give it a try. The idea being that using the official way to cache should be more stable than my work around.
One of my convoluted systems is a Docker image that builds most of the PHP extensions into 1 giant image. I have each extension in one stage of the build so that Docker can build them all at the same time. (That lets me just copy the built files from the image instead of having to rebuild every extension for every php image I have.)
Since some of the extensions require installation of packages via apt, I thought that this would make a good test of using the dedicated RUN cache.
The end result was that the build failed because I had multiple processes trying to get a lock on the /var/cache/apt/archives/lock file.
Now I could just run a sequential build and the problem would go away, but that defeats the entire point of using the cache. (The point being to improve build speeds.)
So, is there a way to use the dedicated RUN cache for this kind of thing?
(FYI, my old way of doing this was basically to run apt update, tag it, then copy the needed apt info from the tagged image into each stage. At the end of each stage I’d delete the copied apt data.)