You can optionally turn on caching for your CI (runCI) jobs to speed up your build by pulling your cache instead of installing all your dependencies. Please note that caching is currently not available for any other job type.

How caching works

If caching is turned on, your cache is updated for every build and is available to subsequent builds. We create a tarball of whatever needs to be cached and upload it to S3 at the end of the build. Caching occurs at the project level only.

Caching per branch is currently unsupported, so your cache will be updated for each build regardless of branch.

The roundtrip to and from S3 means that caching is very useful in specific scenarios and not so much in others:

  • Files that take a long time to install benefit from caching. So anything related to bundler, npm, composer, pip, etc are great candidates for caching.

  • Files that take a long time to download but installed quickly do not benefit from caching since it takes as much time to download from S3 as from the original source. Examples are compiled binaries, JDK packages, etc.

Caching with multiple nodes

You may have setup multiple nodes for a Subscription to run multiple builds in parallel. In this scenario, all nodes will get initialized with the same initial state of the cache and the cache will get updated at the end of each build.

Caching for matrix builds

If you have one node in your plan and run a matrix build with cache turned on, each build in the matrix will update the cache, which will be used by every subsequent build in the matrix.

For matrix builds across multiple nodes, lets assume N nodes and M builds with M > N. The caching for the first N builds will work as mentioned in the previous section. The (N + 1)th build will use the cache created by the last matrix build that completed.

Clearing cache

You can clear cache in one of two ways:

  • Including [reset minion] or [reset_minion] in your commit message.
  • Clicking on Reset cache in your Project Settings UI.

In both cases, your cached content will be deleted before the job is run. This is a one-time action, so if cache is still set to true in your yml, the CI job will generate a new cache which will be used for subsequent builds.

This method is the best way to run a job with no cache without changing your shippable.yml.

Typical use-cases