Use the Volume-cache plugin to preserve files and directories between builds. Because it uses a mounted volume, it requires repositories using it to enable the "Trusted" flag.
The following parameters are used to configure the plugin:
- restore - instruct plugin to restore cache, can be
trueorfalse - rebuild - instruct plugin to rebuild cache, can be
trueorfalse - mount - list of folders or files to cache
- ttl - maximum cache lifetime in days
- cache_key - list of environment variables to use for constructing the cache path
pipeline:
restore-cache:
image: drillster/drone-volume-cache
restore: true
mount:
- ./node_modules
# Mount the cache volume, needs "Trusted"
volumes:
- /tmp/cache:/cache
build:
image: node
commands:
- npm install
rebuild-cache:
image: drillster/drone-volume-cache
rebuild: true
mount:
- ./node_modules
# Mount the cache volume, needs "Trusted"
volumes:
- /tmp/cache:/cacheThe example above illustrates a typical Node.js project Drone configuration. It caches the ./node_modules directory to a mounted volume on the host system: /tmp/cache. This prevents npm from downloading and installing the dependencies for every build.
It is possible to limit the lifetime of cached files and folders.
pipeline:
restore-cache:
image: drillster/drone-volume-cache
restore: true
mount:
- ./node_modules
# Mount the cache volume, needs "Trusted"
volumes:
- /tmp/cache:/cache
ttl: 7The example above shows a situation where cached items older than 7 days will not be restored (they will be removed instead). Only the restore step needs the ttl parameter.
By default, this plugin uses the repo owner, repo name, and job number to construct a cache key. Say the repository owner is foo, the repository name is bar, and the job number is 1,
the cache key (folder) the plugin will use for the build will be foo/bar/1.
If this is not optimal for your specific situation, it is possible to modify the cache key. For example, let's say that your project differs quite a bit between different branches, you may want to include the branch somewhere in the cache key:
pipeline:
restore-cache:
image: drillster/drone-volume-cache
restore: true
mount:
- ./node_modules
# Mount the cache volume, needs "Trusted"
volumes:
- /tmp/cache:/cache
cache_key: [ DRONE_REPO_OWNER, DRONE_REPO_NAME, DRONE_BRANCH, DRONE_JOB_NUMBER ]This would lead to the following cache key if a build is triggered for the master branch (and the rest of the situation is the same as the example illustrated above): foo/bar/master/1.
In theory you could even use this to share cache between different projects, but extreme caution is advised doing so.
Instead of using a cache_key option in your Drone yaml file, you may generate a cache key and write it to the .cache_key file in the root of your repo. If a .cache_key file is present, the first NAME_MAX characters of the first line of this file is read and (by default) its MD5 is used as the actual key for sanitization purposes. You may disable MD5'ing by setting cache_key_disable_sanitize: true.
This feature allows you to generate the cache key dynamically (e.g. by calculating the checksum of your package.json). Note that if a .cache_key file is present, it overrides your settings of cache_key.
pipeline:
build:
image: ubuntu
commands:
- [...]
- echo -n "my custom cache key" > .cache_key
restore-cache:
image: drillster/drone-volume-cache
restore: true
mount:
- ./node_modules
# Mount the cache volume, needs "Trusted"
volumes:
- /tmp/cache:/cacheShould you want to clear the cache for a project, you can do so by including [CLEAR CACHE] in the commit message. The entire cache folder for the project will be cleared before it is restored. The rebuilding of cache will proceed as normal.
If you want to run a build without using cache, put [NO CACHE] in the commit message. Both the restoring and rebuilding of cache will be skipped. Your cache will remain intact.