Run Drone Pipelines Only on Specific Branches or Tags (2026)

Drone pipelines can be configured to run only on specific branches or tags using the when clause with branch and tag conditions.

Let’s see it in action. Imagine you have a .drone.yml file and you want a deployment pipeline to only run when code is pushed to the main branch.

kind: pipeline
type: docker
name: deploy-to-production

steps:
- name: deploy
  image: plugins/drone-deploy
  settings:
    host: production.example.com
    username: deploy_user
    ssh_key:
      from_secret: prod_ssh_key

trigger:
  branch:
  - main

In this example, the deploy-to-production pipeline will only execute when a commit is pushed to the main branch. If you push to develop or any other branch, this pipeline will be skipped.

Now, what if you want to deploy specific versions tagged in your repository? You can use the tag condition. Let’s say you tag releases with a v prefix, like v1.0.0, v1.0.1, etc.

kind: pipeline
type: docker
name: release-build

steps:
- name: build-release
  image: plugins/docker
  settings:
    repo: yourusername/yourrepo
    tags:
    - ${DRONE_TAG} # This uses the Git tag as the Docker image tag

trigger:
  tag:
  - v* # This matches any tag starting with 'v'

This release-build pipeline will only run when a Git tag is pushed. The ${DRONE_TAG} variable automatically populates with the name of the Git tag that triggered the pipeline, which is super handy for versioning your Docker images.

The when clause, which branch and tag are part of, is Drone’s general-purpose conditional execution mechanism. You can combine multiple conditions within a single when block. For instance, you might want a specific pipeline to run only when a push happens to the main branch OR when a tag matching a release pattern is pushed.

kind: pipeline
type: docker
name: deploy-staging-and-release

steps:
- name: deploy-staging
  image: plugins/deploy
  settings:
    host: staging.example.com
    username: deploy_user
    ssh_key:
      from_secret: staging_ssh_key

trigger:
  when:
    branch:
    - main
    or:
    - tag:
      - v*

Here, the deploy-staging-and-release pipeline will run if the trigger is either a push to the main branch OR a push of a tag that starts with v. The or operator is key for combining different triggering events.

You can also use negative matching. Suppose you want a pipeline to run on all branches except main and develop.

kind: pipeline
pipeline: docker
name: feature-branch-tests

steps:
- name: run-unit-tests
  image: golang:1.19
  commands:
  - go test ./...

trigger:
  branch:
  - '!main' # Exclude main
  - '!develop' # Exclude develop

The ! prefix signifies exclusion. This pipeline will run for any branch that is not main or develop. This is useful for running tests or building artifacts for feature branches before they are merged.

It’s also possible to be more precise with branch matching. For example, you can use glob patterns. To run a pipeline on all branches that start with feature/ (e.g., feature/login, feature/user-profile), you could use:

kind: pipeline
type: docker
name: feature-branch-ci

steps:
- name: build-and-lint
  image: node:18
  commands:
  - npm install
  - npm run build
  - npm run lint

trigger:
  branch:
  - feature/*

This pattern feature/* will match any branch that begins with feature/ followed by any characters. This allows for more granular control over when your CI/CD processes are initiated.

The trigger section is evaluated by Drone before any pipeline execution begins. If the conditions specified in the trigger section are not met, Drone simply skips that pipeline for that particular commit or tag. This is fundamental to optimizing your CI/CD workflow, ensuring that expensive or time-consuming operations are only performed when they are truly necessary, such as on release branches or during specific deployment events.

What most people don’t realize is that the branch and tag conditions can accept regular expressions for even more sophisticated matching. For example, to trigger a pipeline on tags that are exactly v1.0.0, v1.1.0, or v2.0.0 but not v1.0.1 or v2.1.0, you could use:

kind: pipeline
type: docker
name: specific-version-deploy

steps:
- name: deploy-exact-version
  image: plugins/drone-deploy
  settings:
    host: specific.example.com
    username: deploy_user
    ssh_key:
      from_secret: specific_ssh_key

trigger:
  tag:
  - ^v(1\.0\.0|1\.1\.0|2\.0\.0)$

The ^ anchors the match to the beginning of the string, $ anchors it to the end, and (1\.0\.0|1\.1\.0|2\.0\.0) uses the | (OR) operator within a group to specify the exact tag patterns. This level of control is powerful for managing complex release strategies.

The next concept you’ll likely encounter is how to manage secrets across different environments or trigger conditions.