Creating and using CI/CD pipelines
Introduced in GitLab 8.8.
NOTE: Tip: Watch our "Mastering continuous software development" webcast to see a comprehensive demo of GitLab CI/CD pipeline.
Pipelines are the top-level component of continuous integration, delivery, and deployment.
- Jobs that define what to run. For example, code compilation or test runs.
- Stages that define when and how to run. For example, that tests run only after code compilation.
If all the jobs in a stage:
- Succeed, the pipeline moves on to the next stage.
- Fail, the next stage is not (usually) executed and the pipeline ends early.
NOTE: Note: If you have a mirrored repository that GitLab pulls from, you may need to enable pipeline triggering in your project's Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates.
Simple pipeline example
As an example, imagine a pipeline consisting of four stages, executed in the following order:
build, with a job called
test, with two jobs called
staging, with a job called
production, with a job called
Introduced in GitLab 8.11.
Pipelines can be complex structures with many sequential and parallel jobs.
To make it easier to understand the flow of a pipeline, GitLab has pipeline graphs for viewing pipelines and their statuses.
Pipeline graphs can be displayed in two different ways, depending on the page you access the graph from.
NOTE: Note: GitLab capitalizes the stages' names when shown in the pipeline graphs (below).
Regular pipeline graphs
Regular pipeline graphs show the names of the jobs of each stage. Regular pipeline graphs can be found when you are on a single pipeline page. For example:
Pipeline mini graphs
Pipeline mini graphs take less space and can tell you at a quick glance if all jobs passed or something failed. The pipeline mini graph can be found when you navigate to:
- The pipelines index page.
- A single commit page.
- A merge request page.
Pipeline mini graphs allow you to see all related jobs for a single commit and the net result of each stage of your pipeline. This allows you to quickly see what failed and fix it.
Stages in pipeline mini graphs are collapsible. Hover your mouse over them and click to expand their jobs.
|Mini graph||Mini graph expanded|
Job ordering in pipeline graphs
Job ordering depends on the type of pipeline graph. For regular pipeline graphs, jobs are sorted by name.
The order of severity is:
How pipeline duration is calculated
Total running time for a given pipeline excludes retries and pending (queued) time.
Each job is represented as a
Period, which consists of:
Period#first(when the job started).
Period#last(when the job finished).
A simple example is:
- A (1, 3)
- B (2, 4)
- C (6, 7)
In the example:
- A begins at 1 and ends at 3.
- B begins at 2 and ends at 4.
- C begins at 6 and ends at 7.
Visually, it can be viewed as:
0 1 2 3 4 5 6 7 AAAAAAA BBBBBBB CCCC
The union of A, B, and C is (1, 4) and (6, 7). Therefore, the total running time is:
(4 - 1) + (7 - 6) => 4
Expanding and collapsing job log sections
Introduced in GitLab 12.0.
Job logs are divided into sections that can be collapsed or expanded.
In the following example:
- Two sections are expanded and can be collapsed.
- One section is collapsed and can be expanded.
Pipelines, and their component jobs and stages, are defined in the
.gitlab-ci.yml file for each project.
For all available configuration options, see the GitLab CI/CD Pipeline Configuration Reference.
Settings and schedules
In addition to configuring jobs through
.gitlab-ci.yml, additional configuration options are available
through the GitLab UI:
- Pipeline settings for each project. For more information, see Pipeline settings.
- Schedules for pipelines. For more information, see Pipeline schedules.
Introduced in GitLab 8.12.
If you have many similar jobs, your pipeline graph becomes long and hard to read.
For that reason, similar jobs can automatically be grouped together. If the job names are formatted in certain ways, they will be collapsed into a single group in regular pipeline graphs (not the mini graphs).
You'll know when a pipeline has grouped jobs if you don't see the retry or cancel button inside them. Hovering over them will show the number of grouped jobs. Click to expand them.
In the pipeline configuration file, job names must include two numbers separated with one of the following (you can even use them interchangeably):
- A space.
- A slash (
- A colon (
More specifically, it uses this regular expression:
How grouping works
The jobs will be ordered by comparing those two numbers from left to right. You usually want the first to be the index and the second the total.
For example, the following jobs will be grouped under a job named
test 0 3
test 1 3
test 2 3
The following jobs will be grouped under a job named
test 1:2 ruby
test 2:2 ruby
The following jobs will be grouped under a job named
test ruby as well:
1/3 test ruby
2/3 test ruby
3/3 test ruby
Pipelines for merge requests
GitLab supports configuring pipelines that run only for merge requests. For more information, see Pipelines for merge requests.
Pipeline status and test coverage report badges are available and configurable for each project.
For information on adding pipeline badges to projects, see Pipeline badges.
Multi-project pipelines (PREMIUM)
Pipelines for different projects can be combined and visualized together.
For more information, see Multi-project pipelines.
Working with pipelines
In general, pipelines are executed automatically and require no intervention once created.
However, there are instances where you'll need to interact with pipelines. These are documented below.
Manually executing pipelines
Pipelines can be manually executed, with predefined or manually-specified variables.
You might do this if the results of a pipeline (for example, a code build) is required outside the normal operation of the pipeline.
To execute a pipeline manually:
- Navigate to your project's CI/CD > Pipelines.
- Click on the Run Pipeline button.
- On the Run Pipeline page:
- Select the branch to run the pipeline for in the Create for field.
- Enter any environment variables required for the pipeline run.
- Click the Create pipeline button.
The pipeline will execute the jobs as configured.
You can find the current and historical pipeline runs under your project's CI/CD > Pipelines page. Clicking on a pipeline will show the jobs that were run for that pipeline.
You can also access pipelines for a merge request by navigating to its Pipelines tab.
Accessing individual jobs
When you access a pipeline, you can see the related jobs for that pipeline.
Clicking on an individual job will show you its job trace, and allow you to:
- Cancel the job.
- Retry the job.
- Erase the job trace.
Seeing the failure reason for jobs
Introduced in GitLab 10.7.
When a pipeline fails or is allowed to fail, there are several places where you can quickly check the reason it failed:
- In the pipeline graph, on the pipeline detail view.
- In the pipeline widgets, in the merge requests and commit pages.
- In the job views, in the global and detailed views of a job.
In each place, if you hover over the failed job you can see the reason it failed.
From GitLab 10.8, you can also see the reason it failed on the Job detail page.
Manual actions from pipeline graphs
Introduced in GitLab 8.15.
Manual actions, configured using the
allow you to require manual interaction before moving forward in the pipeline.
You can do this straight from the pipeline graph. Just click on the play button to execute that particular job.
For example, your pipeline start automatically, but require manual action to
deploy to production. In the example below, the
stage has a job with a manual action.
Specifying variables when running manual jobs
Introduced in GitLab 12.2.
When running manual jobs you can supply additional job specific variables.
You can do this from the job page of the manual job you want to run with additional variables.
This is useful when you want to alter the execution of a job by using environment variables.
Delay a job in a pipeline graph
Introduced in GitLab 11.4.
When you do not want to run a job immediately, you can use the
when:delayed parameter to
delay a job's execution for a certain period.
This is especially useful for timed incremental rollout where new code is rolled out gradually.
For example, if you start rolling out new code and:
- Users do not experience trouble, GitLab can automatically complete the deployment from 0% to 100%.
- Users experience trouble with the new code, you can stop the timed incremental rollout by canceling the pipeline and rolling back to the last stable version.
Using the API
GitLab provides API endpoints to:
- Perform basic functions. For more information, see Pipelines API.
- Maintain pipeline schedules. For more information, see Pipeline schedules API.
- Trigger pipeline runs. For more information, see:
Start multiple manual actions in a stage
Introduced in GitLab 11.11.
Multiple manual actions in a single stage can be started at the same time using the "Play all manual" button. Once the user clicks this button, each individual manual action will be triggered and refreshed to an updated status.
This functionality is only available:
- For users with at least Developer access.
- If the the stage contains manual actions.
Security on protected branches
A strict security model is enforced when pipelines are executed on protected branches.
The following actions are allowed on protected branches only if the user is allowed to merge or push on that specific branch:
- Run manual pipelines (using the Web UI or pipelines API).
- Run scheduled pipelines.
- Run pipelines using triggers.
- Trigger manual actions on existing pipelines.
- Retry or cancel existing jobs (using the Web UI or pipelines API).
Variables marked as protected are accessible only to jobs that run on protected branches, preventing untrusted users getting unintended access to sensitive information like deployment credentials and tokens.
Runners marked as protected can run jobs only on protected branches, avoiding untrusted code to be executed on the protected runner and preserving deployment keys and other credentials from being unintentionally accessed. In order to ensure that jobs intended to be executed on protected runners will not use regular runners, they must be tagged accordingly.