Docker Community Forums

Share and learn in the Docker community.

Docker needs a generalized build caching affordance

Since caching is extremely important and requires domain specific knowledge to do cache invalidation, I think it’s very import for Docker to stop leaning so heavily on its internal build caching, and put some generalized tool into our hands so that we can provide our own caching during builds.

In my specific use-case, I am trying to containerize a Rust project, and the lack of build caching is making this project infeasible. It takes my Rust project more than two hours to compile from scratch, but less than a minute to rebuild from a hot build cache.

Unfortunately, Docker’s internal build cache cannot (at this time) appropriately preserve the cache of built crates: if anything changes, it’s a cold rebuild. The internet is littered with Cargo-specific workarounds to get the crates cached in Docker’s internal build cache, but those workarounds don’t always work, and in particular don’t work when using the Cargo workspaces feature (which I am using).

I really think it’s Docker that needs to throw us a lifeline here. Build caching is of fundamental necessity, why is it so hard?

One way of solving the need is to allow us to mount volumes at build-time. This would work for any caching system, by allowing us to mount a cache of built artifacts at build-time.

Additional benefits beyond allowing domain-specific cache invalidation logic (for finer-grained cache invalidation) include that we could share that cache across builds of different docker images, and between multiple hosts. Moreover, the capability to mount a volume at build time goes beyond build caching and would provide other benefits, such as making it easy to mount package repository mirrors during build time.

Followup: I think that the experimental buildkit backend is trying to address this issue with RUN --mount;

That’s nice!