doc/ci/pipelines/_index.md
{{< details >}}
{{< /details >}}
CI/CD pipelines are the fundamental component of GitLab CI/CD. Pipelines are configured
in a .gitlab-ci.yml file by using YAML keywords.
Pipelines can run automatically for specific events, like when pushing to a branch, creating a merge request, or on a schedule. When needed, you can also run pipelines manually.
Pipelines are composed of:
A small pipeline could consist of three stages, executed in the following order:
build stage, with a job called compile that compiles the project's code.test stage, with two jobs called test1 and test2 that run various tests on the code.
These tests would only run if the compile job completed successfully.deploy stage, with a job called deploy-to-production. This job would only run
if both jobs in the test stage started and completed successfully.To get started with your first pipeline, see Create and run your first GitLab CI/CD pipeline.
Pipelines can be configured in many different ways:
needs keyword run based on dependencies
between jobs and can run more quickly than basic pipelines.Pipelines and their component jobs and stages are defined with YAML keywords in the CI/CD pipeline configuration file for each project. When editing CI/CD configuration in GitLab, you should use the pipeline editor.
You can also configure specific aspects of your pipelines through the GitLab UI:
If you use VS Code to edit your GitLab CI/CD configuration, the GitLab for VS Code extension helps you validate your configuration and view your pipeline status.
{{< history >}}
ci_inputs_for_pipelines. Enabled by default.ci_inputs_for_pipelines removed.{{< /history >}}
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 standard operation of the pipeline.
To execute a pipeline manually:
The pipeline now executes the jobs as configured.
{{< history >}}
ci_show_manual_variables_in_pipeline. Disabled by default.ci_show_manual_variables_in_pipeline removed.{{< /history >}}
You can see all variables that are specified when the pipeline runs manually.
Prerequisites:
The required role depends on what you want to do:
| Action | Minimum role |
|---|---|
| View variable names | Guest |
| View variable values | Developer |
| Configure visibility setting | Owner |
[!warning] When you turn on this setting, users with the Developer role can view variable values that might contain sensitive information from any manual pipeline run. For sensitive data like credentials or tokens, use protected variables or external secrets management instead of manual pipeline variables.
To view manual pipeline variables:
Variable values are masked by default. If you have the Developer, Maintainer, or Owner role, you can select the eye icon to reveal values.
{{< history >}}
{{< /history >}}
You can use the description and value
keywords to define pipeline-level (global) variables
that are prefilled when running a pipeline manually. Use the description to explain
information such as what the variable is used for, and what the acceptable values are.
You can use Markdown in the description.
Job-level variables cannot be pre-filled.
In manually-triggered pipelines, the New pipeline page displays all pipeline-level variables
that have a description defined in the .gitlab-ci.yml file. The description displays
below the variable.
You can change the prefilled value, which overrides the value for that single pipeline run.
Any variables overridden by using this process are expanded
and not masked.
If you do not define a value for the variable in the configuration file, the variable name is still listed,
but the value field is blank.
For example:
variables:
DEPLOY_CREDENTIALS:
description: "The deployment credentials."
DEPLOY_ENVIRONMENT:
description: "Select the deployment target. Valid options are: 'canary', 'staging', 'production', or a stable branch of your choice."
value: "canary"
In this example:
DEPLOY_CREDENTIALS is listed in the New pipeline page, but with no value set.
The user is expected to define the value each time the pipeline is run manually.DEPLOY_ENVIRONMENT is pre-filled in the New pipeline page with canary as the default value,
and the message explains the other options.[!note] Because of a known issue, projects that use compliance pipelines can have prefilled variables not appear when running a pipeline manually. To workaround this issue, change the compliance pipeline configuration.
{{< history >}}
run_pipeline_graphql. Disabled by default.options keyword was introduced in GitLab 15.7.run_pipeline_graphql removed.{{< /history >}}
You can define an array of CI/CD variable values the user can select from when running a pipeline manually.
These values are in a dropdown list in the New pipeline page. Add the list of
value options to options and set the default value with value. The string in value
must also be included in the options list.
For example:
variables:
DEPLOY_ENVIRONMENT:
value: "staging"
options:
- "production"
- "staging"
- "canary"
description: "The deployment target. Set to 'staging' by default."
You can use a query string to pre-populate the New pipeline page. For example, the query string
.../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar pre-populates the
New pipeline page with:
my_branch.foobarfile_foofile_barThe format of the pipelines/new URL is:
.../pipelines/new?ref=<branch>&var[<variable_key>]=<value>&file_var[<file_key>]=<value>
The following parameters are supported:
ref: specify the branch to populate the Run for field with.var: specify a Variable variable.file_var: specify a File variable.For each var or file_var, a key and value are required.
Manual jobs, allow you to require manual interaction before moving forward in the pipeline.
You can do this straight from the pipeline graph. Select Run ({{< icon name="play" >}}) to execute that particular job.
For example, your pipeline can start automatically, but require a manual action to
deploy to production.
In the following example, the production stage has a job with a manual action:
If a stage contains only manual jobs, you can start all the jobs at the same time by selecting Run all manual ({{< icon name="play" >}}) above the stage. If the stage contains non-manual jobs, the option is not displayed.
To push a commit without triggering a pipeline, add [ci skip] or [skip ci], using any
capitalization, to your commit message.
Alternatively, with Git 2.10 or later, use the ci.skip Git push option.
The ci.skip push option does not skip merge request pipelines.
When you skip a pipeline:
skipped in the API.[!note] Pipeline execution policies and scan execution policies can restrict or disable the
[skip ci]directive. For more information, see:
- The
skip_citype in pipeline execution policies.- The
skip_citype in scan execution policies.
Users with the Owner role for a project can delete a pipeline:
#123456789) or the pipeline status icon
(for example Passed) of the pipeline to delete.Deleting a pipeline does not automatically delete its child pipelines. See issue 39503 for more details.
[!warning] Deleting a pipeline expires all pipeline caches, and deletes all immediately related objects, such as jobs, logs, artifacts, and triggers. This action cannot be undone.
A strict security model is enforced when pipelines are executed on protected branches.
The following actions are allowed on protected branches if the user is allowed to merge or push to that specific branch:
Variables marked as protected are accessible to jobs that run in pipelines for protected branches. Only assign users the right to merge to protected branches if they have permission to access 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.
Review how access to protected variables and runners work in the context of Merge request pipelines.
Review the deployment safety page for additional security recommendations for securing your pipelines.
{{< details >}}
{{< /details >}}
You can set up your project to automatically trigger a pipeline based on tags in a different project. When a new tag pipeline in the subscribed project finishes, it triggers a pipeline on your project's default branch, regardless of the tag pipeline's success, failure, or cancellation.
As an alternative, you can use CI/CD jobs with pipeline trigger tokens to trigger pipelines when another pipeline runs. This method is more reliable and flexible than pipeline subscriptions and is the recommended approach.
Prerequisites:
To trigger the pipeline when the upstream project is rebuilt:
<namespace>/<project>.
For example, if the project is https://gitlab.com/gitlab-org/gitlab, use gitlab-org/gitlab.The maximum number of upstream pipeline subscriptions is 2 by default, for both the upstream and downstream projects. On GitLab Self-Managed, an administrator can change this limit.
The total running time for a given pipeline excludes:
That means that if a job is retried or manually re-run, only the duration of the latest run is included in the total running 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:
In the example:
Visually, it can be viewed as:
0 1 2 3 4 5 6 7
AAAAAAA
BBBBBBB
A'A'A'A
CCCC
Because A is retried, it is ignored, and only job A' is counted. The union of B, A', and C is (1, 4) and (6, 7). Therefore, the total running time is:
(4 - 1) + (7 - 6) => 4
To view all the pipelines that ran for your project:
You can filter the Pipelines page by:
Select Pipeline ID in the dropdown list in the upper right to display the pipeline IDs (unique ID across the instance). Select pipeline IID to display the pipeline IIDs (internal ID, unique across the project only).
For example:
To view the pipelines that relate to a specific merge request, go to the Pipelines tab in the merge request.
{{< history >}}
new_pipeline_graph. Disabled by default.{{< /history >}}
Select a pipeline to open the pipeline details page which shows every job in the pipeline. From this page you can cancel a running pipeline, retry failed jobs, or delete a pipeline.
The pipeline details page displays a graph of all the jobs in the pipeline:
You can use a standard URL to access the details for specific pipelines:
gitlab.example.com/my-group/my-project/-/pipelines/latest: The details page
for the latest pipeline for the most recent commit on the default branch in the project.gitlab.example.com/my-group/my-project/-/pipelines/<branch>/latest: The details page
for the latest pipeline for the most recent commit on branch <branch> in the project.needs configurationWhen you configure jobs with the needs keyword, you have
two options for how to group the jobs in the pipeline details page. To group the jobs
by stage configuration, select stage in the Group jobs by section:
To group the jobs by needs configuration, select Job dependencies.
You can optionally select Show dependencies to render lines between dependent jobs.
Jobs in the leftmost column run first, and jobs that depend on them are grouped in the next columns. In this example:
lint-job is configured with needs: [] and depends on no jobs, so it displays in the first column,
despite being in the test stage.test-job1 depends on build-job1, and test-job2 depends on both build-job1 and build-job2,
so both test jobs display in the second column.deploy jobs depend on jobs in second column (which themselves depend on other earlier jobs),
so the deploy jobs display in the third column.When you hover over a job in the Job dependencies view, every job that must run before the selected job is highlighted:
Pipeline mini graphs take less space and can tell you at a quick glance if all jobs passed or something failed. They show all related jobs for a single commit and the net result of each stage of your pipeline. You can quickly see what failed and fix it.
The pipeline mini graph always group jobs by stage, and display throughout GitLab when displaying pipeline or commit details.
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.
When a pipeline contains a job that triggers a downstream pipeline, you can see the downstream pipeline in the pipeline details view and mini graphs.
In the pipeline details view, a card displays for every triggered downstream pipeline on the right of the pipeline graph. Hover over a card to see which job triggered the downstream pipeline. Select a card to display the downstream pipeline to the right of the pipeline graph.
In the pipeline mini graph, the status of every triggered downstream pipeline displays as additional status icons to the right of the mini graph. Select a downstream pipeline status icon to go to the detail page of that downstream pipeline.
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:
When a runner picks a pipeline job, GitLab provides that job's metadata. This includes the Git refspecs, which indicate which ref (such as branch or tag) 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 | +refs/pipelines/<id>:refs/pipelines/<id> |
| pipeline for workload refs | +refs/pipelines/<id>: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.
When a user deletes their GitLab.com account, the deletion does not occur for seven days. During this period, any pipeline subscriptions created by that user continue to run with the user's original permissions. To prevent unauthorized pipeline executions, immediately update pipeline subscription settings for the deleted user.
If the predefined variables for a pipeline are defined in a separate file, they might not display in the New Pipeline page. You must have permission to access the separate file, or else the predefined variables cannot be displayed.