How to Configure a Pipeline in Drone CI

You configure a Drone pipeline by committing a pipeline definition file to your Git repository. Drone reads that file, and for each step it automatically downloads the specified Docker image and runs your commands inside an isolated container. The example on drone.io uses a kind: pipeline file with a steps list, where each step declares a name, an image, and the commands to execute:

kind: pipeline
steps:
  - name: test
    image: node
    commands:
      - npm install
      - npm test
services:
  - name: database
    image: mysql
    ports:
      - 3306

This works for any language, database, or service that runs inside a Docker container, so the same structure applies whether you are testing a Node project or a Python one.

Prerequisites

Before the pipeline runs, you need:

• A repository hosted on a supported source code manager. Drone integrates with GitHub, GitHub Enterprise, Bitbucket, and GitLab.
• Drone installed and connected to that repository. Drone installs from a single binary, and the site points to an official Docker image or building from source.
• A Docker image for each step. You can choose from thousands of public Docker images or provide your own.

The pipeline file structure

The configuration is committed to your Git repository, so it is versioned alongside your code. The key blocks are:

Each step runs inside its own isolated Docker container that is downloaded at runtime. That isolation is what keeps builds from conflicting on a shared server.

Step-by-step: adding a test pipeline

1. Create the pipeline file in your repository. Use the kind: pipeline structure shown above, adjusting image and commands to your project.
2. Define your steps. For a Node project, a test step with image: node and commands npm install then npm test mirrors the documented example. Commands run in order inside the container.
3. Add services if your tests need them. The example declares a database service using image: mysql exposed on port 3306, so the test step can connect to it.
4. Commit and push the file to your Git repository. Because configuration is code, the pipeline definition travels with your commits.
5. Let Drone auto-provision the environment. Drone downloads the images and runs each step in its container; you do not configure build servers by hand.

Expected result: each push triggers the pipeline, and the steps execute in their containers with the output visible in Drone.

Reusing and creating plugins

Drone uses containers to drop pre-configured steps into your pipeline. You can pick from hundreds of existing plugins or create your own. The site lists examples including Docker, Kubernetes, AWS S3, AWS ECR, NPM Publish, GitHub Release, GitHub Pages, Slack Notifications, and Netlify. In practice, a plugin is just a container image referenced as a step, which is why the same image + commands pattern covers both your own steps and published plugins.

Customization and scaling

Beyond the basic file, Drone supports advanced customization: custom access controls, approval workflows, secret management, and YAML syntax extensions. On scaling, the site states Drone installs from a single binary and scales automatically, so you do not have to choose between simplicity and scale.

Common sticking points

• Image availability: a step fails if the referenced image cannot be pulled. Confirm the image name and tag exist, or build and host your own.
• Service readiness: a services container may not be ready the instant a step starts. If your tests connect immediately, expect connection errors until the service is up.
• Command working directory: commands run inside the container, so paths and installed tools must exist in that image, not just on your local machine.
• Secrets: use Drone's secret management rather than hard-coding credentials in the committed file, since the file lives in your repository.

To start, commit a minimal kind: pipeline file with one test step, confirm it runs, then add services and plugins as your needs grow.