The Drone cache plugin doesn’t just save build artifacts; it fundamentally changes how your CI/CD pipeline interacts with disk I/O and network transfers, often making your builds faster than if the cache didn’t exist at all.
Let’s see it in action. Imagine a Go project. A typical build involves downloading dependencies. Without a cache, every go build or go test might re-download modules. With the cache, Drone can store these downloaded modules and reuse them between builds.
Here’s a .drone.yml snippet demonstrating this:
kind: pipeline
type: docker
name: default
steps:
- name: build
image: golang:1.20
commands:
- go build
- go test
volumes:
- name: go-cache
path: /go/pkg/mod
# This is where the magic happens
- uses: plugins/cache
settings:
paths:
- /go/pkg/mod
- name: deploy
image: appleboy/drone-ssh
commands:
- echo "Deploying..."
# Other deployment steps
In this example, the go-cache volume mounts a directory on the host machine (or within the Docker executor’s environment) where Go stores its downloaded modules. The plugins/cache step then tells Drone to:
- Before the build: Download the contents of
/go/pkg/modfrom the cache backend (e.g., S3, GCS, local filesystem). - After the build: Upload the current contents of
/go/pkg/modback to the cache backend, overwriting the previous version.
This simple mechanism drastically cuts down on repetitive downloads. For languages and package managers that rely heavily on external dependencies (like Node.js node_modules, Python venv or .pip, Rust target, Maven .m2, etc.), this is a massive win.
The core problem this solves is the inherent slowness of I/O and network operations in the context of frequent, incremental builds. Each time a build runs, it’s a fresh environment. Without caching, dependencies must be fetched and installed anew. This translates to:
- Increased build times: Waiting for downloads and installations.
- Higher network costs: For cloud-based CI runners, repeated downloads consume bandwidth.
- Unnecessary disk I/O: Writing and reading files that haven’t changed.
The Drone cache plugin acts as a persistent layer between build runs. It intercepts the dependency installation/download process and provides a shortcut. When Drone sees a cache entry for /go/pkg/mod (or whatever path you specify), it first attempts to retrieve that cached data. If it exists, the build step receives the pre-populated directory, bypassing the need to download anything from remote repositories. Only when the cache is missed (first build, or cache invalidated) does the build step actually perform the download. After the step completes, Drone then uploads the new state of that directory back into the cache.
The paths setting is crucial. It specifies which directories Drone should manage. You can list multiple paths, and Drone will create a single archive (or series of archives, depending on the backend) containing all of them. The cache is typically keyed by the pipeline name and branch, meaning the cache for main branch builds is separate from the cache for develop branch builds, preventing cross-branch contamination.
Now, here’s the part most people don’t immediately grasp: the cache plugin doesn’t just save data; it actively manages its lifecycle. When Drone uploads the cache, it’s usually a compressed archive. The plugin unpacks this archive before your build step starts. This unpacking operation, while seemingly an extra step, is almost always orders of magnitude faster than re-downloading potentially gigabytes of dependencies over the network. The true speedup comes from avoiding the network transfer and the remote repository lookup. The local decompression is a cheap price to pay.
The next concept you’ll want to explore is cache invalidation strategies. You might need to explicitly clear or ignore the cache for certain build scenarios, which brings you to advanced cache settings like rebuild and policy.