Advanced local caching
Last updated
Was this helpful?
Earthly 0.6
Last updated
Was this helpful?
In this article we're going to discuss various caching techniques that may be used to optimize your builds. For a primer on the basics of caching, see the .
We will discuss a specific example where dependencies are cached using multiple techniques. Let's take the following build for instance
If we ran this every time we changed the code, then the build would end up downloading all the dependencies specified in Gradle every single time. Here is how this can be improved.
One option is to use layer-based caching to first download all dependencies and only afterwards to copy the code and build it. Thus, when the code changes, the cache is bust after the step where we download dependencies.
This technique is the most simple and most robust technique, however it does not always cover all situations efficiently.
Consider, for instance, a situation where the dependencies themselves change frequently. For example, in Java, if the build has SNAPSHOT dependencies (and/or are marked in Gradle as changing = true), then it needs to download the latest version available for those frequently.
For these cases, the build could use a cache mount. A cache mount is a volume that gets attached to a RUN command and is persisted and shared between runs.
This allows the Gradle command to reuse dependencies downloaded in a previous run and would only download new and updated dependencies, if any apply. It would not download everything from scratch again.
Although this approach works for many situations, it also has some possible downsides. For example, removing a dependency from the gradle spec, will not remove it from the cache. A mild problem can be that the cache becomes bloated over time. A worse possible problem can surface due to build inconsistencies created by the contents of the cache. Although some build tools are smart enough to ignore those cached dependencies if they have been removed from the spec, the behavior will vary from tool to tool and from language to language. In some cases, the build may continue to use a cached but removed dependency, yet if the build is executed on another system, it breaks or behaves differently.
Cache mounts are a leaky abstraction on top of the Earthly base principles by which nothing is shared. Although they are necessary to help optimize builds in some situations, care must be taken of possible edge cases whereby a build behaves differently because of the cache mount alone.
To manage these situations you can elect to reset the cache of a build, by simply running the build again with the flag --no-cache: earthly --no-cache +build. Or, you can eliminate the entire cache altogether using .
To help minimize such edge cases, Earthly only shares cache mounts between repeated builds of the same target, and only if the build args are the same between invocations. For more information see the .