pipelines.md 11.5 KB
Newer Older
1
# Introduction to pipelines and jobs
2

3
> Introduced in GitLab 8.8.
4

5
NOTE: **Note:**
6
If you have a [mirrored repository where GitLab pulls from](https://docs.gitlab.com/ee/workflow/repository_mirroring.html#pulling-from-a-remote-repository-starter),
7 8 9
you may need to enable pipeline triggering in your project's
**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.

10 11
## Pipelines

12
A pipeline is a group of [jobs] that get executed in [stages].
13
All of the jobs in a stage are executed in parallel (if there are enough
14
concurrent [Runners]), and if they all succeed, the pipeline moves on to the
15
next stage. If one of the jobs fails, the next stage is not (usually)
16 17 18 19 20 21 22
executed. You can access the pipelines page in your project's **Pipelines** tab.

In the following image you can see that the pipeline consists of four stages
(`build`, `test`, `staging`, `production`) each one having one or more jobs.

>**Note:**
GitLab capitalizes the stages' names when shown in the [pipeline graphs](#pipeline-graphs).
23

24 25
![Pipelines example](img/pipelines.png)

26
## Types of pipelines
Mark Pundsack's avatar
Mark Pundsack committed
27 28 29

There are three types of pipelines that often use the single shorthand of "pipeline". People often talk about them as if each one is "the" pipeline, but really, they're just pieces of a single, comprehensive pipeline.

30
![Types of Pipelines](img/types-of-pipelines.png)
Mark Pundsack's avatar
Mark Pundsack committed
31

32 33 34
1. **CI Pipeline**: Build and test stages defined in `.gitlab-ci.yml`.
1. **Deploy Pipeline**: Deploy stage(s) defined in `.gitlab-ci.yml` The flow of deploying code to servers through various stages: e.g. development to staging to production.
1. **Project Pipeline**: Cross-project CI dependencies [triggered via API][triggers], particularly for micro-services, but also for complicated build dependencies: e.g. api -> front-end, ce/ee -> omnibus.
Mark Pundsack's avatar
Mark Pundsack committed
35

36
## Development workflows
Mark Pundsack's avatar
Mark Pundsack committed
37 38 39

Pipelines accommodate several development workflows:

40 41 42
1. **Branch Flow** (e.g. different branch for dev, qa, staging, production).
1. **Trunk-based Flow** (e.g. feature branches and single master branch, possibly with tags for releases).
1. **Fork-based Flow** (e.g. merge requests come from forks).
Mark Pundsack's avatar
Mark Pundsack committed
43

Mark Pundsack's avatar
Mark Pundsack committed
44
Example continuous delivery flow:
Mark Pundsack's avatar
Mark Pundsack committed
45

46
![CD Flow](img/pipelines-goal.png)
Mark Pundsack's avatar
Mark Pundsack committed
47

48
## Jobs
49

50 51
Jobs can be defined in the [`.gitlab-ci.yml`][jobs-yaml] file. Not to be
confused with a `build` job or `build` stage.
52 53 54 55 56 57

## Defining pipelines

Pipelines are defined in `.gitlab-ci.yml` by specifying [jobs] that run in
[stages].

58
See the reference [documentation for jobs](yaml/README.md#jobs).
59

60 61 62 63 64 65 66 67 68 69
## Manually executing pipelines

Pipelines can be manually executed, with predefined or manually-specified [variables](variables/README.md).

To execute a pipeline manually:

1. Navigate to your project's **CI/CD > Pipelines**.
1. Click on the **Run Pipeline** button.
1. Select the branch to run the pipeline for and enter any environment variables required for the pipeline run.

70 71
## Seeing pipeline status

72 73 74 75 76
You can find the current and historical pipeline runs under your project's
**Pipelines** tab. Clicking on a pipeline will show the jobs that were run for
that pipeline.

![Pipelines index page](img/pipelines_index.png)
77

78
## Seeing job status
79

80
When you visit a single pipeline you can see the related jobs for that pipeline.
81
Clicking on an individual job will show you its job trace, and allow you to
82 83 84 85
cancel the job, retry it, or erase the job trace.

![Pipelines example](img/pipelines.png)

86 87
## Seeing the failure reason for jobs

88
> [Introduced][ce-17782] in GitLab 10.7.
89 90 91 92 93 94 95 96 97 98 99 100

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** present on the pipeline detail view.
- **In the pipeline widgets** present in the merge requests and commit pages.
- **In the job views** present in the global and detailed views of a job.

In any case, if you hover over the failed job you can see the reason it failed.

![Pipeline detail](img/job_failure_reason.png)

101 102
From [GitLab 10.8][ce-17814] you can also see the reason it failed on the Job detail page.

103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124
## Pipeline graphs

> [Introduced][ce-5742] in GitLab 8.11.

Pipelines can be complex structures with many sequential and parallel jobs.
To make it a little easier to see what is going on, you can view a graph
of a single pipeline and its status.

A pipeline graph can be shown in two different ways depending on what page you
are on.

---

The regular pipeline graph that shows the names of the jobs of each stage can
be found when you are on a [single pipeline page](#seeing-pipeline-status).

![Pipelines example](img/pipelines.png)

Then, there is the pipeline mini graph which takes less space and can give you a
quick glance if all jobs pass or something failed. The pipeline mini graph can
be found when you visit:

125 126 127
- The pipelines index page.
- A single commit page.
- A merge request page.
128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154

That way, you can 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** |
| :------------: | :---------------------: |
| ![Pipelines mini graph](img/pipelines_mini_graph_simple.png) | ![Pipelines mini graph extended](img/pipelines_mini_graph.png) |

### Grouping similar jobs in the pipeline graph

> [Introduced][ce-6242] in GitLab 8.12.

If you have many similar jobs, your pipeline graph becomes very 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.

![Grouped pipelines](img/pipelines_grouped.png)

The basic requirements is that there are two numbers separated with one of
the following (you can even use them interchangeably):

155 156 157
- A space (` `)
- A slash (`/`)
- A colon (`:`)
158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194

>**Note:**
More specifically, [it uses][regexp] this regular expression: `\d+[\s:\/\\]+\d+\s*`.

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`:

- `test 0 3` => `test`
- `test 1 3` => `test`
- `test 2 3` => `test`

The following jobs will be grouped under a job named `test ruby`:

- `test 1:2 ruby` => `test ruby`
- `test 2:2 ruby` => `test ruby`

The following jobs will be grouped under a job named `test ruby` as well:

- `1/3 test ruby` => `test ruby`
- `2/3 test ruby` => `test ruby`
- `3/3 test ruby` => `test ruby`

### Manual actions from the pipeline graph

> [Introduced][ce-7931] in GitLab 8.15.

[Manual actions][manual] allow you to require manual interaction before moving
forward with a particular job in CI. Your entire pipeline can run automatically,
but the actual [deploy to production][env-manual] will require a click.

You can do this straight from the pipeline graph. Just click on the play button
to execute that particular job. For example, in the image below, the `production`
stage has a job with a manual action.

![Pipelines example](img/pipelines.png)
195

196 197 198 199
### Delay a particular job in the pipeline graph

> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21767) in GitLab 11.4.

200
When you do not want to run a job immediately, you can [delay the job to run after a certain period](yaml/README.md#when-delayed).
201
This is especially useful for timed incremental rollout that new code is rolled out gradually.
202
For example, if you start rolling out new code and users do not experience trouble, GitLab automatically completes the deployment from 0% to 100%.
203 204 205 206 207
Alternatively, if you start rolling out and you noticed that a few users experience trouble with the version,
you can stop the timed incremental rollout by canceling the pipeline, and [rolling](environments.md#rolling-back-changes) it back to the stable version.

![Pipelines example](img/pipeline_incremental_rollout.png)

208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
### Ordering of jobs in pipeline graphs

**Regular pipeline graph**

In the single pipeline page, jobs are sorted by name.

**Mini pipeline graph**

> [Introduced][ce-9760] in GitLab 9.0.

In the pipeline mini graphs, the jobs are sorted first by severity and then
by name. The order of severity is:

- failed
- warning
- pending
- running
- manual
226
- scheduled
227 228 229 230 231 232 233
- canceled
- success
- skipped
- created

![Pipeline mini graph sorting](img/pipelines_mini_graph_sorting.png)

234 235 236 237 238 239 240 241 242 243
## How the pipeline duration is calculated

Total running time for a given pipeline would exclude retries and pending
(queue) time. We could reduce this problem down to finding the union of
periods.

So each job would be represented as a `Period`, which consists of
`Period#first` as when the job started and `Period#last` as when the
job was finished. A simple example here would be:

244 245 246
- A (1, 3)
- B (2, 4)
- C (6, 7)
247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264

Here A begins from 1, and ends to 3. B begins from 2, and ends to 4.
C begins from 6, and ends to 7. Visually it could be viewed as:

```
0  1  2  3  4  5  6  7
   AAAAAAA
      BBBBBBB
                  CCCC
```

The union of A, B, and C would be (1, 4) and (6, 7), therefore the
total running time should be:

```
(4 - 1) + (7 - 6) => 4
```

265 266
## Badges

267
Pipeline status and test coverage report badges are available. You can find their
268
respective link in the [Pipelines settings] page.
269

270 271 272 273 274 275 276 277
## Security on protected branches

A strict security model is enforced when pipelines are executed on
[protected branches](../user/project/protected_branches.md).

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:
278 279 280 281 282 283

- Run **manual pipelines** (using [Web UI](#manually-executing-pipelines) or Pipelines API).
- Run **scheduled pipelines**.
- Run pipelines using **triggers**.
- Trigger **manual actions** on existing pipelines.
- **Retry/cancel** existing jobs (using Web UI or Pipelines API).
284

285
**Variables** marked as **protected** are accessible only to jobs that
286 287 288 289 290 291 292 293 294
run on protected branches, avoiding untrusted users to get 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.

295 296
[jobs]: #jobs
[jobs-yaml]: yaml/README.md#jobs
297
[manual]: yaml/README.md#whenmanual
298
[env-manual]: environments.md#manually-deploying-to-environments
299
[stages]: yaml/README.md#stages
300
[runners]: runners/README.html
301
[pipelines settings]: ../user/project/pipelines/settings.md
302
[triggers]: triggers/README.md
303 304 305
[ce-5742]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5742
[ce-6242]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6242
[ce-7931]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7931
306
[ce-9760]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9760
307
[ce-17782]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17782
308
[ce-17814]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17814
309
[regexp]: https://gitlab.com/gitlab-org/gitlab-ce/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99