Drone CI, at its core, acts as a sophisticated Git hook, triggering pipelines based on code changes.
Let’s see it in action. Imagine you have a simple Go application.
kind: pipeline
type: docker
name: default
steps:
- name: build
image: golang:1.19
commands:
- go build
- go test
- name: publish
image: plugins/docker
settings:
username:
from_secret: docker_username
password:
from_secret: docker_password
repo: your-dockerhub-username/your-repo-name
This pipeline is defined in a .drone.yml file in your repository. When you push a commit to your Git repository (e.g., GitHub, GitLab, Bitbucket), Drone is configured to watch for these pushes. If a push occurs, Drone checks if a .drone.yml file exists in the root of the repository. If it does, Drone interprets this file as instructions for a build pipeline.
The pipeline is broken down into steps. Each step runs in its own isolated container, specified by the image field. In our example, the first step uses a golang:1.19 Docker image to build and test the Go application. The second step uses the plugins/docker image to build a Docker image of your application and push it to a registry. The settings within the publish step specify the Docker registry credentials and the repository name, fetching sensitive information like username and password from Drone’s secrets manager.
This declarative approach means you define what you want to happen, not how to orchestrate it. Drone handles the execution. The kind: pipeline and type: docker at the top declare the type of pipeline and the execution environment. name: default gives the pipeline a name, which is useful if you have multiple pipelines in a single repository.
The fundamental problem Drone CI solves is the automation of software delivery. Instead of manually building, testing, and deploying code, Drone automates these repetitive tasks. It integrates directly with your version control system, making the process seamless and triggered by the very actions that signify a change in your codebase. This tight integration ensures that your build and deployment process is always in sync with your code’s state.
Drone’s power comes from its extensibility via plugins and its ability to manage secrets securely. For instance, the plugins/docker step is a pre-built plugin that abstracts away the complexities of interacting with Docker registries. You can find plugins for almost any task: deploying to Kubernetes, sending notifications to Slack, scanning for vulnerabilities, and much more. These plugins are themselves Docker images, meaning Drone can run virtually any tool or service as part of your pipeline.
When you define username: from_secret: docker_username and password: from_secret: docker_password, Drone doesn’t embed these credentials directly into your .drone.yml file. Instead, you configure these secrets within the Drone UI or via its API for your repository. Drone then securely injects these secrets into the build environment when the pipeline runs, preventing sensitive information from being exposed in your source code or pipeline definitions. This is crucial for security.
The core of Drone’s execution model is its reliance on Docker. Every step in your pipeline runs within a Docker container. This provides a clean, isolated, and reproducible build environment. When a pipeline starts, Drone pulls the specified Docker images for each step, creates containers, and executes the commands within them. When the step finishes, the container is discarded, ensuring that each build starts from a fresh slate and avoiding dependency conflicts between different builds or steps.
Most people understand that Drone runs steps in Docker containers. What’s less commonly appreciated is how Drone serializes or parallelizes these steps based on their dependencies and the pipeline configuration. By default, steps are executed sequentially. However, if you have multiple independent steps that don’t rely on each other’s output, Drone can execute them in parallel across available runners, significantly speeding up your build times. This is managed implicitly by Drone’s scheduler, which analyzes the Directed Acyclic Graph (DAG) of your pipeline steps.
The next logical step is to explore how to configure different types of runners for Drone, allowing you to scale your build infrastructure.