GitLab’s robust CI/CD capabilities are a developer’s dream, but sometimes you want to leverage the power and flexibility of Drone CI, especially if your organization has existing investments or specific needs it fulfills. Integrating Drone CI with GitLab repositories means telling Drone where to find your code and how to react to changes, turning your GitLab repo into the trigger for your Drone pipelines.
Let’s see this in action. Imagine you have a GitLab project at gitlab.com/your-username/your-repo. You’ve set up Drone CI, and now you want Drone to build your code whenever you push a commit.
First, you need to authorize Drone to access your GitLab account. This usually involves visiting your Drone settings and clicking a button to connect to GitLab, which will redirect you to GitLab for OAuth approval. Once authorized, Drone can see your repositories.
Next, you’ll create a .drone.yml file in the root of your GitLab repository. This is the heart of your Drone pipeline definition. Here’s a simple example:
kind: pipeline
type: docker
name: default
steps:
- name: build
image: golang:1.18
commands:
- go build
- go test
This tells Drone:
kind: pipeline: This is a pipeline definition.type: docker: The pipeline will run in a Docker container.name: default: The name of this pipeline.steps: A list of sequential commands to execute.build: The name of this step.image: golang:1.18: Use the official Go 1.18 Docker image for this step.commands: The shell commands to run inside the container.
To make Drone aware of this pipeline and link it to your GitLab repo, you’ll add the repository to Drone. In the Drone UI, you’ll typically find a list of repositories you have access to. You’ll find your-username/your-repo and click a toggle or button to "Activate" or "Sync" it. Drone will then automatically start watching for webhook events from GitLab for this repository.
When you push a commit to your-repo on GitLab, GitLab will send a webhook event to your Drone server. Drone receives this event, checks its configuration for your-username/your-repo, finds the .drone.yml file, and starts executing the pipeline defined within it.
The mental model here is that GitLab acts as the source code manager and event generator, while Drone is the execution engine that listens for these events and runs the defined build, test, or deploy processes. You control the "what" and "when" of the pipeline through the .drone.yml file, and you control the "where" and "how" of the integration through Drone’s UI and your GitLab repository settings.
The key levers you control are:
.drone.ymlcontent: This is where you define your entire CI/CD workflow – the stages, the steps within each stage, the Docker images to use, the commands to run, and any dependencies between steps. You can have multiple pipelines defined in this file, triggered by different Git events (push, pull request, tag, etc.).- Drone Repository Settings: In the Drone UI, for each activated repository, you can configure:
- Branch filtering: You can specify which branches should trigger pipelines (e.g., only
mainanddevelop). - Event filtering: You can choose to trigger pipelines on pushes, pull requests, tags, or a combination.
- Environment variables: You can inject secrets and non-secret environment variables into your pipeline steps, crucial for deployment credentials or API keys.
- Build concurrency: Control how many builds can run simultaneously for this repository.
- Branch filtering: You can specify which branches should trigger pipelines (e.g., only
- GitLab Project Settings: On the GitLab side, you can manage the webhooks that GitLab sends to Drone. Drone typically sets these up automatically when you activate a repository, but you can also configure them manually in your GitLab project’s
Settings > Webhooks. This gives you fine-grained control over what events GitLab broadcasts.
A common point of confusion is how Drone gets the source code. When Drone receives a webhook from GitLab, it doesn’t just run commands; it clones the repository first. The git clone operation uses the credentials that Drone has for your GitLab account (either via OAuth or a specific token) to fetch the repository’s content. This is why the initial authorization step is so critical. If Drone can’t authenticate with GitLab, it can’t clone your code, and your pipeline will fail.
The trigger section in your .drone.yml is where you can get really granular about what actions initiate a pipeline run. By default, a push to any branch will trigger the default pipeline. However, you can explicitly define triggers:
kind: pipeline
type: docker
name: pull-request-build
trigger:
event:
- pull_request
steps:
- name: build
image: ubuntu
commands:
- echo "Building a pull request!"
This pipeline will only run when a pull request is opened or updated, not on regular pushes to branches. You can also filter by branch names within the trigger block, like branch: main or branch: ["main", "develop"], to restrict pipeline execution to specific branches. This is incredibly powerful for ensuring that certain pipelines only run on your core development branches or only when specific tags are created.
Once you’ve got basic builds running, the next logical step is to explore how Drone handles different types of Git events, like tags, and how to configure multi-stage pipelines for testing, building artifacts, and deploying.