debian-mirror-gitlab/doc/ci/pipelines/index.md

538 lines
21 KiB
Markdown
Raw Normal View History

2020-04-08 14:13:33 +05:30
---
2020-06-23 00:09:42 +05:30
stage: Verify
group: Continuous Integration
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
2020-04-08 14:13:33 +05:30
disqus_identifier: 'https://docs.gitlab.com/ee/ci/pipelines.html'
type: reference
---
2020-04-22 19:07:51 +05:30
# CI/CD pipelines
2020-04-08 14:13:33 +05:30
> Introduced in GitLab 8.8.
NOTE: **Tip:**
2020-04-22 19:07:51 +05:30
Watch the
2020-04-08 14:13:33 +05:30
["Mastering continuous software development"](https://about.gitlab.com/webcast/mastering-ci-cd/)
2020-04-22 19:07:51 +05:30
webcast to see a comprehensive demo of a GitLab CI/CD pipeline.
2020-04-08 14:13:33 +05:30
Pipelines are the top-level component of continuous integration, delivery, and deployment.
Pipelines comprise:
2020-04-22 19:07:51 +05:30
- 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.
2020-11-24 15:15:51 +05:30
Jobs are executed by [runners](../runners/README.md). Multiple jobs in the same stage are executed in parallel,
2020-04-22 19:07:51 +05:30
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.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
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.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
A typical pipeline might consist of four stages, executed in the following order:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- A `build` stage, with a job called `compile`.
- A `test` stage, with two jobs called `test1` and `test2`.
- A `staging` stage, with a job called `deploy-to-stage`.
- A `production` stage, with a job called `deploy-to-prod`.
2020-04-08 14:13:33 +05:30
NOTE: **Note:**
2020-11-24 15:15:51 +05:30
If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository),
2020-04-08 14:13:33 +05:30
you may need to enable pipeline triggering in your project's
**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
2020-04-22 19:07:51 +05:30
## Types of pipelines
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Pipelines can be configured in many different ways:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- [Basic pipelines](pipeline_architectures.md#basic-pipelines) run everything in each stage concurrently,
followed by the next stage.
- [Directed Acyclic Graph Pipeline (DAG) pipelines](../directed_acyclic_graph/index.md) are based on relationships
between jobs and can run more quickly than basic pipelines.
- [Multi-project pipelines](../multi_project_pipelines.md) combine pipelines for different projects together.
- [Parent-Child pipelines](../parent_child_pipelines.md) 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.
- [Pipelines for Merge Requests](../merge_request_pipelines/index.md) run for merge
requests only (rather than for every commit).
- [Pipelines for Merged Results](../merge_request_pipelines/pipelines_for_merged_results/index.md)
are merge request pipelines that act as though the changes from the source branch have
already been merged into the target branch.
- [Merge Trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md)
use pipelines for merged results to queue merges one after the other.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
## Configure a pipeline
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Pipelines and their component jobs and stages are defined in the CI/CD pipeline configuration file for each project.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- Jobs are the [basic configuration](../yaml/README.md#introduction) component.
- Stages are defined by using the [`stages`](../yaml/README.md#stages) keyword.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
For a list of configuration options in the CI pipeline file, see the [GitLab CI/CD Pipeline Configuration Reference](../yaml/README.md).
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
You can also configure specific aspects of your pipelines through the GitLab UI. For example:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- [Pipeline settings](settings.md) for each project.
- [Pipeline schedules](schedules.md).
2020-05-24 23:13:21 +05:30
- [Custom CI/CD variables](../variables/README.md#custom-environment-variables).
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### View pipelines
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
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.
2020-04-08 14:13:33 +05:30
2020-05-24 23:13:21 +05:30
![Pipelines index page](img/pipelines_index_v13_0.png)
2020-04-08 14:13:33 +05:30
2020-10-24 23:57:45 +05:30
Click a pipeline to open the **Pipeline Details** page and show
2020-04-22 19:07:51 +05:30
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](#delete-a-pipeline).
2020-04-08 14:13:33 +05:30
2020-06-23 00:09:42 +05:30
[Starting in GitLab 12.3](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/50499), a link to the
2020-04-22 19:07:51 +05:30
latest pipeline for the last commit of a given branch is available at `/project/pipelines/[branch]/latest`.
2020-10-24 23:57:45 +05:30
Also, `/project/pipelines/latest` redirects you to the latest pipeline for the last commit
2020-04-22 19:07:51 +05:30
on the project's default branch.
2020-04-08 14:13:33 +05:30
2020-05-24 23:13:21 +05:30
[Starting in GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/215367),
you can filter the pipeline list by:
- Trigger author
- Branch name
2020-06-23 00:09:42 +05:30
- Status ([since GitLab 13.1](https://gitlab.com/gitlab-org/gitlab/-/issues/217617))
- Tag ([since GitLab 13.1](https://gitlab.com/gitlab-org/gitlab/-/issues/217617))
2020-05-24 23:13:21 +05:30
2020-04-22 19:07:51 +05:30
### Run a pipeline manually
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Pipelines can be manually executed, with predefined or manually-specified [variables](../variables/README.md).
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
You might do this if the results of a pipeline (for example, a code build) are required outside the normal
operation of the pipeline.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
To execute a pipeline manually:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
1. Navigate to your project's **CI/CD > Pipelines**.
1. Click on the **Run Pipeline** button.
1. On the **Run Pipeline** page:
1. Select the branch to run the pipeline for in the **Create for** field.
1. Enter any [environment variables](../variables/README.md) required for the pipeline run.
1. Click the **Create pipeline** button.
2020-04-08 14:13:33 +05:30
2020-10-24 23:57:45 +05:30
The pipeline now executes the jobs as configured.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Run a pipeline by using a URL query string
2020-04-08 14:13:33 +05:30
2020-06-23 00:09:42 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24146) in GitLab 12.5.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
You can use a query string to pre-populate the **Run Pipeline** page. For example, the query string
2020-10-24 23:57:45 +05:30
`.../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar` pre-populates the
2020-04-22 19:07:51 +05:30
**Run Pipeline** page with:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- **Run for** field: `my_branch`.
- **Variables** section:
- Variable:
- Key: `foo`
- Value: `bar`
- File:
- Key: `file_foo`
- Value: `file_bar`
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
The format of the `pipelines/new` URL is:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
```plaintext
.../pipelines/new?ref=<branch>&var[<variable_key>]=<value>&file_var[<file_key>]=<value>
```
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
The following parameters are supported:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- `ref`: specify the branch to populate the **Run for** field with.
- `var`: specify a `Variable` variable.
- `file_var`: specify a `File` variable.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
For each `var` or `file_var`, a key and value are required.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Add manual interaction to your pipeline
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7931) in GitLab 8.15.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Manual actions, configured using the [`when:manual`](../yaml/README.md#whenmanual) parameter,
allow you to require manual interaction before moving forward in the pipeline.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
You can do this straight from the pipeline graph. Just click the play button
to execute that particular job.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
For example, your pipeline might start automatically, but it requires manual action to
2020-05-24 23:13:21 +05:30
[deploy to production](../environments/index.md#configuring-manual-deployments). In the example below, the `production`
2020-04-22 19:07:51 +05:30
stage has a job with a manual action.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Pipelines example](img/pipelines.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
#### Start multiple manual actions in a stage
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/27188) in GitLab 11.11.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Multiple manual actions in a single stage can be started at the same time using the "Play all manual" button.
2020-10-24 23:57:45 +05:30
Once you click this button, each individual manual action is triggered and refreshed
2020-04-22 19:07:51 +05:30
to an updated status.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
This functionality is only available:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- For users with at least Developer access.
- If the stage contains [manual actions](#add-manual-interaction-to-your-pipeline).
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Delete a pipeline
2020-04-08 14:13:33 +05:30
2020-06-23 00:09:42 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24851) in GitLab 12.7.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Users with [owner permissions](../../user/permissions.md) in a project can delete a pipeline
by clicking on the pipeline in the **CI/CD > Pipelines** to get to the **Pipeline Details**
page, then using the **Delete** button.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Pipeline Delete Button](img/pipeline-delete.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
CAUTION: **Warning:**
2020-10-24 23:57:45 +05:30
Deleting a pipeline expires all pipeline caches, and deletes all related objects,
2020-04-22 19:07:51 +05:30
such as builds, logs, artifacts, and triggers. **This action cannot be undone.**
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Pipeline quotas
2020-04-08 14:13:33 +05:30
Each user has a personal pipeline quota that tracks the usage of shared runners in all personal projects.
2020-11-24 15:15:51 +05:30
Each group has a [usage quota](../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes) that tracks the usage of shared runners for all projects created within the group.
2020-04-08 14:13:33 +05:30
When a pipeline is triggered, regardless of who triggered it, the pipeline quota for the project owner's [namespace](../../user/group/index.md#namespaces) is used. In this case, the namespace can be the user or group that owns the project.
2020-04-22 19:07:51 +05:30
#### How pipeline duration is calculated
2020-04-08 14:13:33 +05:30
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:
2020-05-24 23:13:21 +05:30
```plaintext
2020-04-08 14:13:33 +05:30
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:
2020-05-24 23:13:21 +05:30
```plaintext
2020-04-08 14:13:33 +05:30
(4 - 1) + (7 - 6) => 4
```
2020-04-22 19:07:51 +05:30
### Pipeline security on protected branches
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
A strict security model is enforced when pipelines are executed on
[protected branches](../../user/project/protected_branches.md).
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
The following actions are allowed on protected branches only if the user is
[allowed to merge or push](../../user/project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings)
on that specific branch:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- Run manual pipelines (using the [Web UI](#run-a-pipeline-manually) or [pipelines API](#pipelines-api)).
- Run scheduled pipelines.
- Run pipelines using triggers.
2020-10-24 23:57:45 +05:30
- Run on-demand DAST scan.
2020-04-22 19:07:51 +05:30
- Trigger manual actions on existing pipelines.
- Retry or cancel existing jobs (using the Web UI or pipelines API).
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
**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.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
**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. In order to ensure that jobs intended to be executed on protected
2020-10-24 23:57:45 +05:30
runners do not use regular runners, they must be tagged accordingly.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
## View jobs in a pipeline
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
When you access a pipeline, you can see the related jobs for that pipeline.
2020-04-08 14:13:33 +05:30
2020-10-24 23:57:45 +05:30
Clicking an individual job shows you its job log, and allows you to:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- Cancel the job.
- Retry the job.
- Erase the job log.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### See why a job failed
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17782) in GitLab 10.7.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
When a pipeline fails or is allowed to fail, there are several places where you
can find the reason:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- In the [pipeline graph](#visualize-pipelines), 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.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
In each place, if you hover over the failed job you can see the reason it failed.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Pipeline detail](img/job_failure_reason.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
In [GitLab 10.8](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17814) and later,
you can also see the reason it failed on the Job detail page.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### The order of jobs in a pipeline
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
The order of jobs in a pipeline depends on the type of pipeline graph.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- For [regular pipeline graphs](#regular-pipeline-graphs), jobs are sorted by name.
- For [pipeline mini graphs](#pipeline-mini-graphs), jobs are sorted by severity and then by name.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
The order of severity is:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- failed
- warning
- pending
- running
- manual
- scheduled
- canceled
- success
- skipped
- created
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
For example:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Pipeline mini graph sorting](img/pipelines_mini_graph_sorting.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Group jobs in a pipeline
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6242) in GitLab 8.12.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
If you have many similar jobs, your [pipeline graph](#visualize-pipelines) becomes long and hard
to read.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
You can automatically group similar jobs together. If the job names are formatted in a certain way,
2020-10-24 23:57:45 +05:30
they are collapsed into a single group in regular pipeline graphs (not the mini graphs).
2020-04-08 14:13:33 +05:30
2020-10-24 23:57:45 +05:30
You can recognize when a pipeline has grouped jobs if you don't see the retry or
cancel button inside them. Hovering over them shows the number of grouped
2020-04-22 19:07:51 +05:30
jobs. Click to expand them.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Grouped pipelines](img/pipelines_grouped.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
To create a group of jobs, in the [CI/CD pipeline configuration file](../yaml/README.md),
separate each job name with a number and one of the following:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- A slash (`/`), for example, `test 1/3`, `test 2/3`, `test 3/3`.
- A colon (`:`), for example, `test 1:3`, `test 2:3`, `test 3:3`.
- A space, for example `test 0 3`, `test 1 3`, `test 2 3`.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
You can use these symbols interchangeably.
2020-04-08 14:13:33 +05:30
2020-10-24 23:57:45 +05:30
In the example below, these three jobs are in a group named `build ruby`:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
```yaml
build ruby 1/3:
stage: build
script:
2020-07-28 23:09:34 +05:30
- echo "ruby1"
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
build ruby 2/3:
stage: build
script:
2020-07-28 23:09:34 +05:30
- echo "ruby2"
2020-05-24 23:13:21 +05:30
2020-04-22 19:07:51 +05:30
build ruby 3/3:
stage: build
script:
2020-07-28 23:09:34 +05:30
- echo "ruby3"
2020-04-22 19:07:51 +05:30
```
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
In the pipeline, the result is a group named `build ruby` with three jobs:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Job group](img/job_group_v12_10.png)
2020-04-08 14:13:33 +05:30
2020-10-24 23:57:45 +05:30
The jobs are be ordered by comparing the numbers from left to right. You
2020-04-22 19:07:51 +05:30
usually want the first number to be the index and the second number to be the total.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
[This regular expression](https://gitlab.com/gitlab-org/gitlab/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99)
evaluates the job names: `\d+[\s:\/\\]+\d+\s*`.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Specifying variables when running manual jobs
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30485) in GitLab 12.2.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
When running manual jobs you can supply additional job specific variables.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
You can do this from the job page of the manual job you want to run with
2020-05-24 23:13:21 +05:30
additional variables. To access this page, click on the **name** of the manual job in
the pipeline view, *not* the play (**{play}**) button.
2020-04-08 14:13:33 +05:30
2020-05-24 23:13:21 +05:30
This is useful when you want to alter the execution of a job that uses
[custom environment variables](../variables/README.md#custom-environment-variables).
2020-10-24 23:57:45 +05:30
Add a variable name (key) and value here to override the value defined in
2020-05-24 23:13:21 +05:30
[the UI or `.gitlab-ci.yml`](../variables/README.md#custom-environment-variables),
for a single run of the manual job.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Manual job variables](img/manual_job_variables.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Delay a job
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21767) in GitLab 11.4.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
When you do not want to run a job immediately, you can use the [`when:delayed`](../yaml/README.md#whendelayed) parameter to
delay a job's execution for a certain period.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
This is especially useful for timed incremental rollout where new code is rolled out gradually.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
For example, if you start rolling out new code and:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- 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
2020-05-24 23:13:21 +05:30
and [rolling](../environments/index.md#retrying-and-rolling-back) back to the last stable version.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Pipelines example](img/pipeline_incremental_rollout.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Expand and collapse job log sections
2020-04-08 14:13:33 +05:30
2020-06-23 00:09:42 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/14664) in GitLab 12.0.
2020-04-08 14:13:33 +05:30
2020-10-24 23:57:45 +05:30
Job logs are divided into sections that can be collapsed or expanded. Each section displays
2020-04-22 19:07:51 +05:30
the duration.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
In the following example:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- Two sections are collapsed and can be expanded.
- Three sections are expanded and can be collapsed.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Collapsible sections](img/collapsible_log_v12_6.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
#### Custom collapsible sections
2020-04-08 14:13:33 +05:30
2020-10-24 23:57:45 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/14664) in GitLab 12.0.
You can create [collapsible sections in job logs](../pipelines/index.md#expand-and-collapse-job-log-sections)
by manually outputting special codes
that GitLab uses to determine what sections to collapse:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- Section start marker: `section_start:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K` + `TEXT_OF_SECTION_HEADER`
- Section end marker: `section_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K`
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
You must add these codes to the script section of the CI configuration. For example,
using `echo`:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
```yaml
job1:
script:
- echo -e "section_start:`date +%s`:my_first_section\r\e[0KHeader of the 1st collapsible section"
- echo 'this line should be hidden when collapsed'
- echo -e "section_end:`date +%s`:my_first_section\r\e[0K"
```
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
In the example above:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- `date +%s`: The Unix timestamp (for example `1560896352`).
- `my_first_section`: The name given to the section.
- `\r\e[0K`: Prevents the section markers from displaying in the rendered (colored)
job log, but they are displayed in the raw job log. To see them, in the top right
of the job log, click **{doc-text}** (**Show complete raw**).
- `\r`: carriage return.
- `\e[0K`: clear line ANSI escape code.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Sample raw job log:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
```plaintext
section_start:1560896352:my_first_section\r\e[0KHeader of the 1st collapsible section
this line should be hidden when collapsed
section_end:1560896353:my_first_section\r\e[0K
```
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
## Visualize pipelines
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5742) in GitLab 8.11.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Pipelines can be complex structures with many sequential and parallel jobs.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
To make it easier to understand the flow of a pipeline, GitLab has pipeline graphs for viewing pipelines
and their statuses.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Pipeline graphs can be displayed in two different ways, depending on the page you
access the graph from.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
NOTE: **Note:**
GitLab capitalizes the stages' names in the pipeline graphs.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Regular pipeline graphs
Regular pipeline graphs show the names of the jobs in each stage. Regular pipeline graphs can
be found when you are on a [single pipeline page](#view-pipelines). For example:
2020-04-08 14:13:33 +05:30
![Pipelines example](img/pipelines.png)
2020-11-24 15:15:51 +05:30
[Multi-project pipeline graphs](../multi_project_pipelines.md#multi-project-pipeline-visualization) help
2020-04-22 19:07:51 +05:30
you visualize the entire pipeline, including all cross-project inter-dependencies. **(PREMIUM)**
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Pipeline mini graphs
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
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:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
- The pipelines index page.
- A single commit page.
- A merge request page.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
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.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
Stages in pipeline mini graphs are collapsible. Hover your mouse over them and click to expand their jobs.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
| Mini graph | Mini graph expanded |
|:-------------------------------------------------------------|:---------------------------------------------------------------|
| ![Pipelines mini graph](img/pipelines_mini_graph_simple.png) | ![Pipelines mini graph extended](img/pipelines_mini_graph.png) |
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Pipeline success and duration charts
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
> - Introduced in GitLab 3.1.1 as Commit Stats, and later renamed to Pipeline Charts.
2020-06-23 00:09:42 +05:30
> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/38318) to CI / CD Analytics in GitLab 12.8.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
GitLab tracks the history of your pipeline successes and failures, as well as how long each pipeline ran. To view this information, go to **Analytics > CI / CD Analytics**.
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
View successful pipelines:
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
![Successful pipelines](img/pipelines_success_chart.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
View pipeline duration history:
![Pipeline duration](img/pipelines_duration_chart.png)
2020-04-08 14:13:33 +05:30
2020-04-22 19:07:51 +05:30
### Pipeline badges
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](settings.md#pipeline-badges).
## Pipelines API
2020-04-08 14:13:33 +05:30
GitLab provides API endpoints to:
- Perform basic functions. For more information, see [Pipelines API](../../api/pipelines.md).
- Maintain pipeline schedules. For more information, see [Pipeline schedules API](../../api/pipeline_schedules.md).
- Trigger pipeline runs. For more information, see:
- [Triggering pipelines through the API](../triggers/README.md).
- [Pipeline triggers API](../../api/pipeline_triggers.md).