- Types of pipelines
- Configure a pipeline
- Visualize pipelines
- Pipelines API
CI/CD pipelines
Pipelines are the top-level component of continuous integration, delivery, and deployment.
Pipelines comprise:
- Jobs, which define what to do. For example, jobs that compile or test code.
- Stages, which define when to run the jobs. For example, stages that run tests after stages that compile the code.
Jobs are executed by runners. Multiple jobs in the same stage are executed in parallel, if there are enough concurrent runners.
If all jobs in a stage succeed, the pipeline moves on to the next stage.
If any job in a stage fails, the next stage is not (usually) executed and the pipeline ends early.
In general, pipelines are executed automatically and require no intervention once created. However, there are also times when you can manually interact with a pipeline.
A typical pipeline might consist of four stages, executed in the following order:
- A
build
stage, with a job calledcompile
. - A
test
stage, with two jobs calledtest1
andtest2
. - A
staging
stage, with a job calleddeploy-to-stage
. - A
production
stage, with a job calleddeploy-to-prod
.
Types of pipelines
Pipelines can be configured in many different ways:
- Basic pipelines run everything in each stage concurrently, followed by the next stage.
- Directed Acyclic Graph Pipeline (DAG) pipelines are based on relationships between jobs and can run more quickly than basic pipelines.
- Merge request pipelines run for merge requests only (rather than for every commit).
- Merged results pipelines are merge request pipelines that act as though the changes from the source branch have already been merged into the target branch.
- Merge trains use merged results pipelines to queue merges one after the other.
- Parent-child pipelines break down complex pipelines into one parent pipeline that can trigger multiple child sub-pipelines, which all run in the same project and with the same SHA. This pipeline architecture is commonly used for mono-repos.
- Multi-project pipelines combine pipelines for different projects together.
How parent-child pipelines compare to multi-project pipelines
Parent-child pipelines and multi-project pipelines can sometimes be used for similar purposes, but there are some key differences:
Parent-child pipelines:
- Run under the same project, ref, and commit SHA as the parent pipeline.
- Affect the overall status of the ref the pipeline runs against. For example,
if a pipeline fails for the main branch, it’s common to say that “main is broken”.
The status of child pipelines don’t directly affect the status of the ref, unless the child
pipeline is triggered with
strategy:depend
. - Are automatically canceled if the pipeline is configured with
interruptible
when a new pipeline is created for the same ref. - Display only the parent pipelines in the pipeline index page. Child pipelines are visible when visiting their parent pipeline’s page.
- Are limited to 2 levels of nesting. A parent pipeline can trigger multiple child pipelines,
and those child pipeline can trigger multiple child pipelines (
A -> B -> C
).
Multi-project pipelines:
- Are triggered from another pipeline, but the upstream (triggering) pipeline does not have much control over the downstream (triggered) pipeline. However, it can choose the ref of the downstream pipeline, and pass CI/CD variables to it.
- Affect the overall status of the ref of the project it runs in, but does not
affect the status of the triggering pipeline’s ref, unless it was triggered with
strategy:depend
. - Are not automatically canceled in the downstream project when using
interruptible
if a new pipeline runs for the same ref in the upstream pipeline. They can be automatically canceled if a new pipeline is triggered for the same ref on the downstream project. - Multi-project pipelines are standalone pipelines because they are normal pipelines that happened to be triggered by an external project. They are all visible on the pipeline index page.
- Are independent, so there are no nesting limits.
Configure a pipeline
Pipelines and their component jobs and stages are defined in the CI/CD pipeline configuration file for each project.
For a list of configuration options in the CI pipeline file, see the GitLab CI/CD Pipeline Configuration Reference.
You can also configure specific aspects of your pipelines through the GitLab UI. For example:
- Pipeline settings for each project.
- Pipeline schedules.
- Custom CI/CD variables.
Ref specs for runners
When a runner picks a pipeline job, GitLab provides that job’s metadata. This includes the ,
which indicate which ref (branch, tag, and so on) and commit (SHA1) are checked out from your
project repository.
This table lists the refspecs injected for each pipeline type:
Pipeline type | Refspecs |
---|---|
pipeline for branches |
+<sha>:refs/pipelines/<id> and +refs/heads/<name>:refs/remotes/origin/<name>
|
pipeline for tags |
+<sha>:refs/pipelines/<id> and +refs/tags/<name>:refs/tags/<name>
|
merge request pipeline | +<sha>:refs/pipelines/<id>
|
The refs refs/heads/<name>
and refs/tags/<name>
exist in your
project repository. GitLab generates the special ref refs/pipelines/<id>
during a
running pipeline job. This ref can be created even after the associated branch or tag has been
deleted. It’s therefore useful in some features such as automatically stopping an environment,
and merge trains
that might run pipelines after branch deletion.
View pipelines
You can find the current and historical pipeline runs under your project’s CI/CD > Pipelines page. You can also access pipelines for a merge request by navigating to its Pipelines tab.
Select a pipeline to open the Pipeline Details page and show the jobs that were run for that pipeline. From here you can cancel a running pipeline, retry jobs on a failed pipeline, or delete a pipeline.
/project/pipelines/[branch]/latest.
Also, ,
you can filter the pipeline list by:
If you use VS Code to edit your GitLab CI/CD configuration, the
GitLab Workflow VS Code extension helps you
validate your configuration
and view your pipeline status.
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) are required outside the normal
operation of the pipeline.
To execute a pipeline manually:
The pipeline now executes the jobs as configured.
You can use the In pipelines triggered manually, the Run pipelines page displays all top-level variables
with a The description is displayed next to the variable. It can be used to explain what
the variable is used for, what the acceptable values are, and so on:
You cannot set job-level variables to be pre-filled when you run a pipeline manually.
You can use a query string to pre-populate the Run Pipeline page. For example, the query string
The format of the The following parameters are supported:
For each Manual jobs,
allow you to require manual interaction before moving forward in the pipeline.
You can do this straight from the pipeline graph. Just select the play button
to execute that particular job.
For example, your pipeline can start automatically, but require a manual action to
deploy to production.
In the example below, the
Multiple manual actions in a single stage can be started at the same time using the “Play all manual”
After you select this action, each individual manual action is triggered and refreshed
to an updated status.
This functionality is only available:
To push a commit without triggering a pipeline, add Alternatively, if you are using Git 2.10 or later, use the
Users with the Owner role for a project can delete a pipeline
by clicking on the pipeline in the CI/CD > Pipelines to get to the Pipeline Details
page, then selecting Delete.
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:
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, preventing untrusted code from executing on the protected runner and
preserving deployment keys and other credentials from being unintentionally
accessed. To ensure that jobs intended to be executed on protected
runners do not use regular runners, they must be tagged accordingly.
Total running time for a given pipeline excludes retries and pending
(queued) time.
Each job is represented as a A simple example is:
In the example:
Visually, it can be viewed as:
The union of A, B, and C is (1, 4) and (6, 7). Therefore, the total running time is:
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 as a large graph or a miniature representation, depending on the page you
access the graph from.
GitLab capitalizes the stages’ names in the pipeline graphs.
The pipeline details page displays the full pipeline graph of
all the jobs in the pipeline.
You can group the jobs by:
Stage, which arranges jobs in the same stage together in the same column:
Job dependencies, which arranges
jobs based on their Multi-project pipeline graphs help
you visualize the entire pipeline, including all cross-project inter-dependencies.
If a stage contains more than 100 jobs, only the first 100 jobs are listed in the
pipeline graph. The remaining jobs still run as normal. To see the jobs:
You can arrange jobs in the pipeline graph based on their Jobs in the leftmost column run first, and jobs that depend on them are grouped in the next columns.
For example, To add lines that show the To see the full 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 go to:
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.
Pipeline mini graphs only display jobs by stage.
Stages in pipeline mini graphs are expandable. Hover your mouse over each stage to see the name and status, and select a stage to expand its jobs list.
Pipeline analytics are available on the CI/CD Analytics page.
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.
GitLab provides API endpoints to:
If you didn't find what you were looking for,
search the docs.
If you want help with something specific and could use community support,
.
For problems setting up or using this feature (depending on your GitLab
subscription)./project/pipelines/latest
redirects you to the latest pipeline for the last commit
on the project’s default branch.
Run a pipeline manually
Prefill variables in manual pipelines
value
and description
keywords to define
pipeline-level (global) variables
that are prefilled when running a pipeline manually.
description
and value
defined in the .gitlab-ci.yml
file. The values
can then be modified if needed, which overrides the value for that single pipeline run.
variables:
DEPLOY_ENVIRONMENT:
value: "staging" # Deploy to staging by default
description: "The deployment target. Change this variable to 'canary' or 'production' if needed."
Run a pipeline by using a URL query string
.../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar
pre-populates the
Run Pipeline page with:
my_branch
.
foo
bar
file_foo
file_bar
pipelines/new
URL is:
.../pipelines/new?ref=<branch>&var[<variable_key>]=<value>&file_var[<file_key>]=<value>
ref
: specify the branch to populate the Run for field with.
var
: specify a Variable
variable.
file_var
: specify a File
variable.
var
or file_var
, a key and value are required.
Add manual interaction to your pipeline
production
stage has a job with a manual action:
Start multiple manual actions in a stage
Skip a pipeline
[ci skip]
or [skip ci]
, using any
capitalization, to your commit message.
ci.skip
Git push option.
The ci.skip
push option does not skip merge request
pipelines.
Delete a pipeline
Pipeline security on protected branches
How pipeline duration is calculated
Period
, which consists of:
Period#first
(when the job started).
Period#last
(when the job finished).
0 1 2 3 4 5 6 7
AAAAAAA
BBBBBBB
CCCC
(4 - 1) + (7 - 6) => 4
Visualize pipelines
View full pipeline graph
needs
dependencies.
View job dependencies in the pipeline graph
needs
dependencies.
test-job1
depends only on jobs in the first column, so it displays
in the second column from the left. deploy-job1
depends on jobs in both the first
and second column and displays in the third column:
needs
relationships between jobs, select the Show dependencies toggle.
These lines are similar to the needs visualization:
needs
dependency tree for a job, hover over it:
Pipeline mini graphs
Mini graph
Mini graph expanded
Pipeline success and duration charts
Pipeline badges
Pipelines API
Help & feedback
Docs
Edit this page
to fix an error or add an improvement in a merge request.
Create an issue
to suggest an improvement to this page.
Product
Create an issue
if there's something you don't like about this feature.
Propose functionality
by submitting a feature request.
to help shape new features.
Feature availability and product trials
to see all GitLab tiers and features, or to upgrade.
with access to all features for 30 days.
Get Help