--ciin your invocation of
earthlyin your CI, or
--use-inline-cacheon individual developer's machines. If the
--pushcommand is also specified, the use of the cache will be read-write.
SAVE IMAGE --pushdeclarations as source and destination for any inline cache.
SAVE IMAGE --cache-from=.... This may be useful so that PR builds are able to use the main branch cache. Here is a simple example:
apt-get installcommand. Reusing the cache improves performance by a factor of 4X.
SAVE IMAGE --pushcommands. So there is no performance penalty on the cache upload side. The command that would be used in the CI to execute the builds together with inline caching is
--remote-cache=...to specify the Docker tag to use as cache. Make sure that this Docker tag is not used for anything else (e.g. DO NOT use
myimage:latest, in case
latestis used in a critical workflow).
mycompany/myimage:cache, then the flag can be used as follows.
SAVE IMAGE --push .... If additional targets need to be added as part of the cache, it is possible to add
SAVE IMAGE --cache-hint(no Docker tag necessary) at the end, in order to mark them for explicit caching.
--max-remote-cachecan be used to enable this. Note that this results in large uploads and is usually not very effective. An example where this feature is useful, however, is when you would like to optimize CI run times in PRs, and are willing to sacrifice CI run times in default branch builds. This can be achieved by enabling
--max-remote-cacheon the default branch builds only.
+project-filesis perfect for introducing a cache hint via
SAVE IMAGE --cache-hint. The processing that takes place as part of installing Scala and compiling the dependencies is sufficiently compute-intensive to save ~2 min from the total build time in CI. In addition, these dependencies change rarely enough that the cache can be utilized consistently.
SAVE IMAGE --pushcommand adds more cacheable targets in the form of separate images. However, in the case of explicit caching, the entire cache is stored as part of a single Docker tag and every
SAVE IMAGE --cache-hintcommand adds more cacheable targets within the image. This final image containing all the explicit cache cannot be used for anything else. So as a user, you incur the performance cost of both the upload and the subsequent download.
earthlyinvocations in CI)
SAVE IMAGE --push <docker-tag>commands
SAVE IMAGE --cache-hintcommands
apktool shipped in
alpineimages. Installing packages via
apkis download-heavy, but usually not very compute-heavy, and so using shared caching to offset
apkdownload times might not be as effective. On the other hand, consider
apt-gettool shipped in
ubuntuimages. Besides performing downloads,
apt-getalso performs additional post-download steps which tend to be compute-intensive. For this reason, shared caching is usually very effective here.
apt-get, similar remarks can be made about the various language-specific dependency management tools. Some will be pure download-based (e.g.
go mod download), while others will be a mix of download and computation (.e.g
FROM +some-targetinstruction versus just using the previously built image directly. If
SAVE IMAGE --push myimage:latestinstruction, then the performance becomes almost the same to using