Feature Requests

We are using a shared image the cache mount in the dockerfile: ONBUILD RUN --mount=type=cache,target=/var/lib/apt/lists,sharing=locked \ apt update ... This image is then used as the root image in another dockerfile. When this second docker image is build, it fails because of: failed to solve: cannot mount from stage "scratch" to "/var/lib/apt/lists", stage needs to be defined before current command A work around was found by defining FROM scratch as scratch and FROM parent as parent in the child docker image, but this is cumbersome. The build should work just like it does locally.

For organizations that have projects with different cache lifetimes, it would be helpful to be able to set the storage days on each individual project.

Rebuild without cache is, for certain toolchains, a very useful feature. Sorry to see it going in v2. As cache keys are now totally transparent, it seems like a purge by key system is the closest the new infrastructure can come to this. An extension to the idea might be to have a 'purge caches used in this build' button too CCI-I-362

With increased popularity of lerna / yarn workspaces monorepos, support for things like this seems to be a must: save_cache: key: core-dependencies-{{ checksum "yarn.lock" }} paths: - node_modules - packages/*/node_modules CCI-I-239

Since late 2022, CircleCI has rolled out a new Docker Layer Caching (DLC) implementation: https://discuss.circleci.com/t/fyi-small-dlc-update-no-action-required/44614 Currently (as of May 2023), we noted there is a cache size limit of 15 GB; Images pulled or built that are larger than this limit will be purged (not saved). It would be great if we can allow users to increase this cache limit. Perhaps versioned via the paid plan tiers, or choosing the "resource size" for DLC storage.

Currently, DLC only applies to the actual building of Docker images within jobs. It'd be nice to enable DLC for the actual spin up of environment Docker images, since those tend to vary wildly from just a few seconds to a few minutes. Enabling DLC will allow for consistently fast spinup of environment. CCI-I-1004

It's useful that run steps can be set to background: true but this doesn't work for save_cache steps which can take up to 30 seconds in my experience. These don't need to hold up the rest of the run and would make my whole process a lot faster (as I have 4 save_cache calls) CCI-I-1226

Add "Clearing cache" button on each project settings page

Adding the ability to run restore_cache on a step failure would allow for saving time on potentially expensive post-failure actions. This could help with cleanup steps or aggregation steps.

Add a possibility to always save the cache whether it is a hit w r t key or not. The usecase is Flatpak builds. These always builds dependencies from scratch. These builds are stored in a cache. flatpak-builder knows whether the data ithis cache is valid or not. caching this cache (sic!) saves a lot of build time, about 25 minutes in our opencpn case. Saving the cache is less than 15 seconds, so it's worth it. The problem is just that no key can be constructed which reflects if the cache is valid. Thus, the sane approach is to save the cache in each build, leaving it to flatpak-builder to decide what is usable. But I see no clean way to do this. There are work arounds, but certainly nothing clean to be proud of.