Drone CI’s volume mount is the closest thing you’ll get to persistent storage within a pipeline step, but it’s not a magic bullet for true persistence.
Here’s a Drone pipeline that uses a volume to share a downloaded tool between steps:
kind: pipeline
type: docker
name: default
steps:
- name: download-tool
image: alpine:latest
commands:
- apk update && apk add --no-cache curl
- curl -LO https://example.com/my-tool.tar.gz
- tar xzf my-tool.tar.gz
- mv my-tool /drone/volume/
volumes:
- name: tool-cache
path: /drone/volume/
- name: use-tool
image: alpine:latest
commands:
- /drone/volume/my-tool/bin/my-tool --version
volumes:
- name: tool-cache
path: /drone/volume/
volumes:
- name: tool-cache
host: {}
This pipeline first downloads my-tool.tar.gz in the download-tool step. It then extracts the tool into /drone/volume/. Crucially, the tool-cache volume is declared and mounted to /drone/volume/ in this step.
In the subsequent use-tool step, the same tool-cache volume is mounted to the identical path, /drone/volume/. This makes the extracted my-tool available for execution, demonstrating how data can be passed between steps. The host: {} configuration for the volume tells Drone to use the host machine’s filesystem for this volume, but the exact location is managed by Drone itself.
The core problem Drone’s volumes solve is inter-step data sharing within the same pipeline execution. Without them, each step starts with a clean slate, and any files created in one step are lost before the next one begins. This is essential for scenarios like caching dependencies, sharing build artifacts, or passing configuration files generated in earlier stages.
Internally, when you declare a volume with host: {}, Drone orchestrates the creation and mounting of a directory on the underlying execution host (whether that’s a Docker daemon, Kubernetes, etc.). For Docker, this often translates to a bind mount. When a step is launched, Drone ensures that the directory associated with that volume name is mounted at the specified path within the container. When the step finishes, the container is ephemeral, but the data within the mounted volume on the host persists. The next step that mounts the same volume name to the same path will have that data available.
The most surprising true thing about Drone volumes is that they are not truly persistent across pipeline runs. If you stop a pipeline mid-execution and then restart it, the volumes will be reset. They only persist for the duration of a single, uninterrupted pipeline execution. This is a key distinction from more robust storage solutions like persistent volumes in Kubernetes, which are designed for long-term data retention.
The host: {} configuration is a bit of a misnomer; you don’t directly specify a path on the host. Drone manages the lifecycle of these host-level directories. You can, however, use specific volume drivers if your underlying platform supports them (e.g., Kubernetes persistentVolumeClaim names), which offers more control over storage allocation and persistence policies.
The next concept you’ll likely encounter is managing secrets within your pipeline, which often involves a similar volume-based injection mechanism.