README.md 151 KB
Newer Older
Marcia Ramos's avatar
Marcia Ramos committed
1
---
2 3
stage: Verify
group: Continuous Integration
4
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/#assignments
Marcia Ramos's avatar
Marcia Ramos committed
5 6 7
type: reference
---

Evan Read's avatar
Evan Read committed
8
# GitLab CI/CD pipeline configuration reference
9

10
This document lists the configuration options for your GitLab `.gitlab-ci.yml` file.
11

12
- For a quick introduction to GitLab CI/CD, follow the [quick start guide](../quick_start/README.md).
Evan Read's avatar
Evan Read committed
13
- For a collection of examples, see [GitLab CI/CD Examples](../examples/README.md).
14
- To view a large `.gitlab-ci.yml` file used in an enterprise, see the [`.gitlab-ci.yml` file for `gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
15

16 17
When you are editing your `.gitlab-ci.yml` file, you can validate it with the
[CI Lint](../lint.md) tool.
Evan Read's avatar
Evan Read committed
18

19
## Job keywords
Evan Read's avatar
Evan Read committed
20

21
A job is defined as a list of keywords that define the job's behavior.
Evan Read's avatar
Evan Read committed
22

23
The keywords available for jobs are:
Evan Read's avatar
Evan Read committed
24

25 26
| Keyword                                            | Description                                                                                                                                                                         |
|:---------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
27
| [`script`](#script)                                | Shell script that is executed by a runner.                                                                                                                                          |
28
| [`after_script`](#after_script)                    | Override a set of commands that are executed after job.                                                                                                                             |
29
| [`allow_failure`](#allow_failure)                  | Allow job to fail. A failed job does not cause the pipeline to fail.                                                                                                                                          |
30
| [`artifacts`](#artifacts)                          | List of files and directories to attach to a job on success. Also available: `artifacts:paths`, `artifacts:exclude`, `artifacts:expose_as`, `artifacts:name`, `artifacts:untracked`, `artifacts:when`, `artifacts:expire_in`, and `artifacts:reports`. |
31
| [`before_script`](#before_script)                  | Override a set of commands that are executed before job.                                                                                                                            |
32
| [`cache`](#cache)                                  | List of files that should be cached between subsequent runs. Also available: `cache:paths`, `cache:key`, `cache:untracked`, `cache:when`, and `cache:policy`.                       |
33
| [`coverage`](#coverage)                            | Code coverage settings for a given job.                                                                                                                                             |
34
| [`dependencies`](#dependencies)                    | Restrict which artifacts are passed to a specific job by providing a list of jobs to fetch artifacts from.                                                                          |
35
| [`environment`](#environment)                      | Name of an environment to which the job deploys. Also available: `environment:name`, `environment:url`, `environment:on_stop`, `environment:auto_stop_in`, and `environment:action`. |
36
| [`except`](#onlyexcept-basic)                      | Limit when jobs are not created. Also available: [`except:refs`, `except:kubernetes`, `except:variables`, and `except:changes`](#onlyexcept-advanced).                              |
37
| [`extends`](#extends)                              | Configuration entries that this job inherits from.                                                                                                                                  |
38
| [`image`](#image)                                  | Use Docker images. Also available: `image:name` and `image:entrypoint`.                                                                                                             |
39
| [`include`](#include)                              | Include external YAML files. Also available: `include:local`, `include:file`, `include:template`, and `include:remote`.                                                             |
40 41 42 43
| [`interruptible`](#interruptible)                  | Defines if a job can be canceled when made redundant by a newer run.                                                                                                                |
| [`only`](#onlyexcept-basic)                        | Limit when jobs are created. Also available: [`only:refs`, `only:kubernetes`, `only:variables`, and `only:changes`](#onlyexcept-advanced).                                          |
| [`pages`](#pages)                                  | Upload the result of a job to use with GitLab Pages.                                                                                                                                |
| [`parallel`](#parallel)                            | How many instances of a job should be run in parallel.                                                                                                                              |
Suzanne Selhorn's avatar
Suzanne Selhorn committed
44
| [`release`](#release)                              | Instructs the runner to generate a [Release](../../user/project/releases/index.md) object.                                                                                          |
45
| [`resource_group`](#resource_group)                | Limit job concurrency.                                                                                                                                                              |
46
| [`retry`](#retry)                                  | When and how many times a job can be auto-retried in case of a failure.                                                                                                             |
47
| [`rules`](#rules)                                  | List of conditions to evaluate and determine selected attributes of a job, and whether or not it's created. May not be used alongside `only`/`except`.                              |
48 49
| [`services`](#services)                            | Use Docker services images. Also available: `services:name`, `services:alias`, `services:entrypoint`, and `services:command`.                                                       |
| [`stage`](#stage)                                  | Defines a job stage (default: `test`).                                                                                                                                              |
50
| [`tags`](#tags)                                    | List of tags that are used to select a runner.                                                                                                                                      |
51 52 53
| [`timeout`](#timeout)                              | Define a custom job-level timeout that takes precedence over the project-wide setting.                                                                                              |
| [`trigger`](#trigger)                              | Defines a downstream pipeline trigger.                                                                                                                                              |
| [`variables`](#variables)                          | Define job variables on a job level.                                                                                                                                                |
54
| [`when`](#when)                                    | When to run job. Also available: `when:manual` and `when:delayed`.                                                                                                                  |
Evan Read's avatar
Evan Read committed
55

56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
### Unavailable names for jobs

Each job must have a unique name, but there are a few **reserved `keywords` that
can't be used as job names**:

- `image`
- `services`
- `stages`
- `types`
- `before_script`
- `after_script`
- `variables`
- `cache`
- `include`

71
### Reserved keywords
72

73
If you get a validation error when using specific values (for example, `true` or `false`), try to:
74 75 76 77

- Quote them.
- Change them to a different form. For example, `/bin/true`.

78 79 80 81
## Global keywords

Some keywords are defined at a global level and affect all jobs in the pipeline.

82
### Global defaults
Kamil Trzciński's avatar
Kamil Trzciński committed
83

84
Some keywords can be set globally as the default for all jobs with the
85
`default:` keyword. Default keywords can then be overridden by job-specific
Kamil Trzciński's avatar
Kamil Trzciński committed
86 87
configuration.

88
The following job keywords can be defined inside a `default:` block:
Kamil Trzciński's avatar
Kamil Trzciński committed
89 90 91

- [`image`](#image)
- [`services`](#services)
92 93
- [`before_script`](#before_script)
- [`after_script`](#after_script)
94
- [`tags`](#tags)
Kamil Trzciński's avatar
Kamil Trzciński committed
95
- [`cache`](#cache)
96
- [`artifacts`](#artifacts)
97
- [`retry`](#retry)
98
- [`timeout`](#timeout)
99
- [`interruptible`](#interruptible)
Kamil Trzciński's avatar
Kamil Trzciński committed
100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115

In the following example, the `ruby:2.5` image is set as the default for all
jobs except the `rspec 2.6` job, which uses the `ruby:2.6` image:

```yaml
default:
  image: ruby:2.5

rspec:
  script: bundle exec rspec

rspec 2.6:
  image: ruby:2.6
  script: bundle exec rspec
```

116
#### `inherit`
117

118
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207484) in GitLab 12.9.
119 120

You can disable inheritance of globally defined defaults
121
and variables with the `inherit:` keyword.
122

123
To enable or disable the inheritance of all `default:` or `variables:` keywords, use:
124 125 126 127

- `default: true` or `default: false`
- `variables: true` or `variables: false`

128
To inherit only a subset of `default:` keywords or `variables:`, specify what
129
you wish to inherit. Anything not listed is **not** inherited. Use
130 131 132 133
one of the following formats:

```yaml
inherit:
134
  default: [keyword1, keyword2]
135 136 137 138 139 140 141 142
  variables: [VARIABLE1, VARIABLE2]
```

Or:

```yaml
inherit:
  default:
143 144
    - keyword1
    - keyword2
145 146 147 148 149
  variables:
    - VARIABLE1
    - VARIABLE2
```

150 151
In the example below:

152
- `rubocop`:
Suzanne Selhorn's avatar
Suzanne Selhorn committed
153
  - inherits: Nothing.
154
- `rspec`:
Suzanne Selhorn's avatar
Suzanne Selhorn committed
155 156
  - inherits: the default `image` and the `WEBHOOK_URL` variable.
  - does **not** inherit: the default `before_script` and the `DOMAIN` variable.
157
- `capybara`:
Suzanne Selhorn's avatar
Suzanne Selhorn committed
158 159
  - inherits: the default `before_script` and `image`.
  - does **not** inherit: the `DOMAIN` and `WEBHOOK_URL` variables.
160
- `karma`:
Suzanne Selhorn's avatar
Suzanne Selhorn committed
161 162
  - inherits: the default `image` and `before_script`, and the `DOMAIN` variable.
  - does **not** inherit: `WEBHOOK_URL` variable.
163 164 165

```yaml
default:
166
  image: 'ruby:2.4'
167 168 169 170 171
  before_script:
    - echo Hello World

variables:
  DOMAIN: example.com
172
  WEBHOOK_URL: https://my-webhook.example.com
173 174

rubocop:
175 176 177
  inherit:
    default: false
    variables: false
178 179 180 181
  script: bundle exec rubocop

rspec:
  inherit:
182 183
    default: [image]
    variables: [WEBHOOK_URL]
184 185 186 187 188 189
  script: bundle exec rspec

capybara:
  inherit:
    variables: false
  script: bundle exec capybara
190 191 192 193 194 195

karma:
  inherit:
    default: true
    variables: [DOMAIN]
  script: karma
196 197
```

198
### `stages`
Evan Read's avatar
Evan Read committed
199

200 201 202
Use `stages` to define stages that contain groups of jobs. `stages` is defined globally
for the pipeline. Use [`stage`](#stage) in a job to define which stage the job is
part of.
Evan Read's avatar
Evan Read committed
203

204
The order of the `stages` items defines the execution order for jobs:
Evan Read's avatar
Evan Read committed
205

206 207
- Jobs in the same stage run in parallel.
- Jobs in the next stage run after the jobs from the previous stage complete successfully.
208

209
For example:
Evan Read's avatar
Evan Read committed
210 211

```yaml
212 213 214 215
stages:
  - build
  - test
  - deploy
Evan Read's avatar
Evan Read committed
216 217
```

218 219 220 221
1. All jobs in `build` execute in parallel.
1. If all jobs in `build` succeed, the `test` jobs execute in parallel.
1. If all jobs in `test` succeed, the `deploy` jobs execute in parallel.
1. If all jobs in `deploy` succeed, the pipeline is marked as `passed`.
222

223 224
If any job fails, the pipeline is marked as `failed` and jobs in later stages do not
start. Jobs in the current stage are not stopped and continue to run.
Evan Read's avatar
Evan Read committed
225

226 227 228 229 230 231 232
If no `stages` are defined in `.gitlab-ci.yml`, then `build`, `test` and `deploy`
are the default pipeline stages.

If a job does not specify a [`stage`](#stage), the job is assigned the `test` stage.

To make a job start earlier and ignore the stage order, use
the [`needs`](#needs) keyword.
Evan Read's avatar
Evan Read committed
233

234
### `workflow:rules`
Evan Read's avatar
Evan Read committed
235

236
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29654) in GitLab 12.5
237

238
The top-level `workflow:` keyword determines whether or not a pipeline is created.
239
It accepts a single `rules:` keyword that is similar to [`rules:` defined in jobs](#rules).
240
Use it to define what can trigger a new pipeline.
241

242 243
You can use the [`workflow:rules` templates](#workflowrules-templates) to import
a preconfigured `workflow: rules` entry.
244

245
`workflow: rules` accepts these keywords:
246

247
- [`if`](#rulesif): Check this rule to determine when to run a pipeline.
248
- [`when`](#when): Specify what to do when the `if` rule evaluates to true.
249 250
  - To run a pipeline, set to `always`.
  - To prevent pipelines from running, set to `never`.
251

252
When no rules evaluate to true, the pipeline does not run.
253

254
Some example `if` clauses for `workflow: rules`:
255 256 257 258 259 260 261 262

| Example rules                                        | Details                                                   |
|------------------------------------------------------|-----------------------------------------------------------|
| `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'` | Control when merge request pipelines run.                 |
| `if: '$CI_PIPELINE_SOURCE == "push"'`                | Control when both branch pipelines and tag pipelines run. |
| `if: $CI_COMMIT_TAG`                                 | Control when tag pipelines run.                           |
| `if: $CI_COMMIT_BRANCH`                              | Control when branch pipelines run.                        |

263 264
See the [common `if` clauses for `rules`](#common-if-clauses-for-rules) for more examples.

Suzanne Selhorn's avatar
Suzanne Selhorn committed
265
For example, in the following configuration, pipelines run for all `push` events (changes to
266 267 268
branches and new tags). Pipelines for push events with `-wip` in the commit message
don't run, because they are set to `when: never`. Pipelines for schedules or merge requests
don't run either, because no rules evaluate to true for them:
269 270 271 272

```yaml
workflow:
  rules:
273
    - if: $CI_COMMIT_MESSAGE =~ /-wip$/
274
      when: never
275 276 277
    - if: '$CI_PIPELINE_SOURCE == "push"'
```

278
This example has strict rules, and pipelines do **not** run in any other case.
279

280 281 282
Alternatively, all of the rules can be `when: never`, with a final
`when: always` rule. Pipelines that match the `when: never` rules do not run.
All other pipeline types run:
283 284 285 286 287 288 289

```yaml
workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
      when: never
    - if: '$CI_PIPELINE_SOURCE == "push"'
290 291 292 293
      when: never
    - when: always
```

294
This example prevents pipelines for schedules or `push` (branches and tags) pipelines.
295
The final `when: always` rule runs all other pipeline types, **including** merge
296
request pipelines.
297

298 299
If your rules match both branch pipelines and merge request pipelines,
[duplicate pipelines](#prevent-duplicate-pipelines) can occur.
300

301 302 303 304
#### `workflow:rules` templates

> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217732) in GitLab 13.0.

Suzanne Selhorn's avatar
Suzanne Selhorn committed
305 306
We provide templates that set up `workflow: rules`
for common scenarios. These templates help prevent duplicate pipelines.
307 308 309 310

The [`Branch-Pipelines` template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Workflows/Branch-Pipelines.gitlab-ci.yml)
makes your pipelines run for branches and tags.

311
Branch pipeline status is displayed in merge requests that use the branch
312 313
as a source. However, this pipeline type does not support any features offered by
[Merge Request Pipelines](../merge_request_pipelines/), like
314
[Pipelines for Merge Results](../merge_request_pipelines/#pipelines-for-merged-results)
315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337
or [Merge Trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/).
Use this template if you are intentionally avoiding those features.

It is [included](#include) as follows:

```yaml
include:
  - template: 'Workflows/Branch-Pipelines.gitlab-ci.yml'
```

The [`MergeRequest-Pipelines` template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Workflows/MergeRequest-Pipelines.gitlab-ci.yml)
makes your pipelines run for the default branch (usually `master`), tags, and
all types of merge request pipelines. Use this template if you use any of the
the [Pipelines for Merge Requests features](../merge_request_pipelines/), as mentioned
above.

It is [included](#include) as follows:

```yaml
include:
  - template: 'Workflows/MergeRequest-Pipelines.gitlab-ci.yml'
```

338
### `include`
Evan Read's avatar
Evan Read committed
339

340
> - Introduced in [GitLab Premium](https://about.gitlab.com/pricing/) 10.5.
341
> - Available for Starter, Premium, and Ultimate in GitLab 10.6 and later.
Marcel Amirault's avatar
Marcel Amirault committed
342
> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/42861) to GitLab Core in 11.4.
Evan Read's avatar
Evan Read committed
343

344 345 346 347 348
Use the `include` keyword to include external YAML files in your CI/CD configuration.
You can break down one long `gitlab-ci.yml` into multiple files to increase readability,
or reduce duplication of the same configuration in multiple places.

You can also store template files in a central repository and `include` them in projects.
349

350
`include` requires the external YAML file to have the extensions `.yml` or `.yaml`,
Suzanne Selhorn's avatar
Suzanne Selhorn committed
351
otherwise the external file is not included.
Evan Read's avatar
Evan Read committed
352

353 354 355
You can't use [YAML anchors](#anchors) across different YAML files sourced by `include`.
You can only refer to anchors in the same file. Instead of YAML anchors, you can
use the [`extends` keyword](#extends).
356

357 358
`include` supports the following inclusion methods:

359
| Keyword                          | Method                                                       |
360 361 362 363
|:--------------------------------|:------------------------------------------------------------------|
| [`local`](#includelocal)        | Include a file from the local project repository.                 |
| [`file`](#includefile)          | Include a file from a different project repository.               |
| [`remote`](#includeremote)      | Include a file from a remote URL. Must be publicly accessible.    |
364
| [`template`](#includetemplate)  | Include templates that are provided by GitLab.                    |
365

366 367
The `include` methods do not support [variable expansion](../variables/where_variables_can_be_used.md#variables-usage).

368 369
`.gitlab-ci.yml` configuration included by all methods is evaluated at pipeline creation.
The configuration is a snapshot in time and persisted in the database. Any changes to
Suzanne Selhorn's avatar
Suzanne Selhorn committed
370
referenced `.gitlab-ci.yml` configuration is not reflected in GitLab until the next pipeline is created.
371

372
The files defined by `include` are:
Evan Read's avatar
Evan Read committed
373

374 375 376
- Deep merged with those in `.gitlab-ci.yml`.
- Always evaluated first and merged with the content of `.gitlab-ci.yml`,
  regardless of the position of the `include` keyword.
Evan Read's avatar
Evan Read committed
377

378 379
TIP: **Tip:**
Use merging to customize and override included CI/CD configurations with local
Suzanne Selhorn's avatar
Suzanne Selhorn committed
380
definitions. Local definitions in `.gitlab-ci.yml` override included definitions.
Evan Read's avatar
Evan Read committed
381

382
#### `include:local`
Evan Read's avatar
Evan Read committed
383

384
`include:local` includes a file from the same repository as `.gitlab-ci.yml`.
385
It's referenced with full paths relative to the root directory (`/`).
Evan Read's avatar
Evan Read committed
386

Suzanne Selhorn's avatar
Suzanne Selhorn committed
387
You can only use files that are tracked by Git on the same branch
388
your configuration file is on. If you `include:local`, make
389
sure that both `.gitlab-ci.yml` and the local file are on the same branch.
Evan Read's avatar
Evan Read committed
390

391
You can't include local files through Git submodules paths.
392

Suzanne Selhorn's avatar
Suzanne Selhorn committed
393
All [nested includes](#nested-includes) are executed in the scope of the same project,
Marcel Amirault's avatar
Marcel Amirault committed
394
so it's possible to use local, project, remote, or template includes.
Evan Read's avatar
Evan Read committed
395

396
Example:
Evan Read's avatar
Evan Read committed
397

398 399 400 401
```yaml
include:
  - local: '/templates/.gitlab-ci-template.yml'
```
Evan Read's avatar
Evan Read committed
402

403
Local includes can be used as a replacement for symbolic links that are not followed.
404 405 406 407 408 409 410

This can be defined as a short local include:

```yaml
include: '.gitlab-ci-production.yml'
```

411
#### `include:file`
Evan Read's avatar
Evan Read committed
412

413
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53903) in GitLab 11.7.
Evan Read's avatar
Evan Read committed
414

415
To include files from another private project under the same GitLab instance,
416
use `include:file`. This file is referenced with full paths relative to the
417
root directory (`/`). For example:
Evan Read's avatar
Evan Read committed
418

419 420 421 422 423
```yaml
include:
  - project: 'my-group/my-project'
    file: '/templates/.gitlab-ci-template.yml'
```
Evan Read's avatar
Evan Read committed
424

425
You can also specify a `ref`. If not specified, it defaults to the `HEAD` of the project:
Evan Read's avatar
Evan Read committed
426

427 428 429 430 431
```yaml
include:
  - project: 'my-group/my-project'
    ref: master
    file: '/templates/.gitlab-ci-template.yml'
Evan Read's avatar
Evan Read committed
432

433 434 435
  - project: 'my-group/my-project'
    ref: v1.0.0
    file: '/templates/.gitlab-ci-template.yml'
Kamil Trzcinski's avatar
Kamil Trzcinski committed
436

437
  - project: 'my-group/my-project'
Marcel Amirault's avatar
Marcel Amirault committed
438
    ref: 787123b47f14b552955ca2786bc9542ae66fee5b  # Git SHA
439 440
    file: '/templates/.gitlab-ci-template.yml'
```
441

442
All [nested includes](#nested-includes) are executed in the scope of the target project.
443
You can use local (relative to target project), project, remote, or template includes.
444

445 446 447
##### Multiple files from a project

> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26793) in GitLab 13.6.
448 449 450 451
> - It's [deployed behind a feature flag](../../user/feature_flags.md), enabled by default.
> - It's enabled on GitLab.com.
> - It's recommended for production use.
> - For GitLab self-managed instances, GitLab administrators can opt to disable it. **(CORE ONLY)**
452 453 454 455 456 457 458 459 460 461 462 463

You can include multiple files from the same project:

```yaml
include:
  - project: 'my-group/my-project'
    ref: master
    file:
      - '/templates/.builds.yml'
      - '/templates/.tests.yml'
```

464 465
Including multiple files from the same project is under development but ready for production use. It is
deployed behind a feature flag that is **enabled by default**.
466
[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md)
467
can opt to disable it.
468 469 470 471 472 473 474 475 476 477 478 479 480

To enable it:

```ruby
Feature.enable(:ci_include_multiple_files_from_project)
```

To disable it:

```ruby
Feature.disable(:ci_include_multiple_files_from_project)
```

481 482 483
#### `include:remote`

`include:remote` can be used to include a file from a different location,
484 485
using HTTP/HTTPS, referenced by the full URL. The remote file must be
publicly accessible by a GET request, because authentication schemas
486 487 488 489 490 491 492
in the remote URL are not supported. For example:

```yaml
include:
  - remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'
```

493 494
All [nested includes](#nested-includes) are executed without context as a public user,
so you can only `include` public projects or templates.
495

496
#### `include:template`
497

498
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53445) in GitLab 11.7.
499

500 501
`include:template` can be used to include `.gitlab-ci.yml` templates that are
[shipped with GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates).
502

503
For example:
504

505
```yaml
506 507 508
# File sourced from GitLab's template collection
include:
  - template: Auto-DevOps.gitlab-ci.yml
509 510
```

511
Multiple `include:template` files:
512

513 514 515 516 517
```yaml
include:
  - template: Android-Fastlane.gitlab-ci.yml
  - template: Auto-DevOps.gitlab-ci.yml
```
518

Suzanne Selhorn's avatar
Suzanne Selhorn committed
519
All [nested includes](#nested-includes) are executed only with the permission of the user,
Marcel Amirault's avatar
Marcel Amirault committed
520
so it's possible to use project, remote or template includes.
521

522
#### Nested includes
523

524
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56836) in GitLab 11.9.
525

526
Use nested includes to compose a set of includes.
527

528
You can have up to 100 includes, but you can't have duplicate includes.
529

530
In [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/28212) and later, the time limit
531
to resolve all files is 30 seconds.
532

533
#### Additional `includes` examples
534

535
There is a list of [additional `includes` examples](includes.md) available.
536

537
## Keyword details
538

539
The following are detailed explanations for keywords used to configure CI/CD pipelines.
540

541
### `image`
542

543
Used to specify [a Docker image](../docker/using_docker_images.md#what-is-an-image) to use for the job.
544

545
For:
546

547
- Usage examples, see [Define `image` and `services` from `.gitlab-ci.yml`](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
548
- Detailed usage information, refer to [Docker integration](../docker/README.md) documentation.
549

550
#### `image:name`
551

552
An [extended Docker configuration option](../docker/using_docker_images.md#extended-docker-configuration-options).
553

554
For more information, see [Available settings for `image`](../docker/using_docker_images.md#available-settings-for-image).
555

556
#### `image:entrypoint`
557

558
An [extended Docker configuration option](../docker/using_docker_images.md#extended-docker-configuration-options).
559

560
For more information, see [Available settings for `image`](../docker/using_docker_images.md#available-settings-for-image).
561

562
#### `services`
563

564
Used to specify a [service Docker image](../docker/using_docker_images.md#what-is-a-service), linked to a base image specified in [`image`](#image).
565

566
For:
567

568
- Usage examples, see [Define `image` and `services` from `.gitlab-ci.yml`](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
569 570
- Detailed usage information, refer to [Docker integration](../docker/README.md) documentation.
- For example services, see [GitLab CI/CD Services](../services/README.md).
571

572
##### `services:name`
573

574
An [extended Docker configuration option](../docker/using_docker_images.md#extended-docker-configuration-options).
575

576
For more information, see [Available settings for `services`](../docker/using_docker_images.md#available-settings-for-services).
577

578
##### `services:alias`
579

580
An [extended Docker configuration option](../docker/using_docker_images.md#extended-docker-configuration-options).
581

582
For more information, see [Available settings for `services`](../docker/using_docker_images.md#available-settings-for-services).
583

584
##### `services:entrypoint`
585

586
An [extended Docker configuration option](../docker/using_docker_images.md#extended-docker-configuration-options).
587

588
For more information, see [Available settings for `services`](../docker/using_docker_images.md#available-settings-for-services).
589

590
##### `services:command`
591

592
An [extended Docker configuration option](../docker/using_docker_images.md#extended-docker-configuration-options).
593

594
For more information, see [Available settings for `services`](../docker/using_docker_images.md#available-settings-for-services).
595

596 597 598
### `script`

`script` is the only required keyword that a job needs. It's a shell script
599
that is executed by the runner. For example:
600 601

```yaml
602 603
job:
  script: "bundle exec rspec"
604 605
```

606
You can use [YAML anchors with `script`](#yaml-anchors-for-scripts).
607

608
This keyword can also contain several commands in an array:
609 610

```yaml
611 612 613 614
job:
  script:
    - uname -a
    - bundle exec rspec
615 616
```

Suzanne Selhorn's avatar
Suzanne Selhorn committed
617
Sometimes, `script` commands must be wrapped in single or double quotes.
618 619
For example, commands that contain a colon (`:`) must be wrapped in quotes.
The YAML parser needs to interpret the text as a string rather than
620 621
a "key: value" pair. Be careful when using special characters:
`:`, `{`, `}`, `[`, `]`, `,`, `&`, `*`, `#`, `?`, `|`, `-`, `<`, `>`, `=`, `!`, `%`, `@`, `` ` ``.
622

Suzanne Selhorn's avatar
Suzanne Selhorn committed
623
If any of the script commands return an exit code other than zero, the job
624 625
fails and further commands are not executed. Store the exit code in a variable to
avoid this behavior:
626

627 628 629 630 631 632
```yaml
job:
  script:
    - false || exit_code=$?
    - if [ $exit_code -ne 0 ]; then echo "Previous command failed"; fi;
```
633

634
#### `before_script`
635

636 637
`before_script` is used to define an array of commands that should run before each job,
but after [artifacts](#artifacts) are restored.
drew cimino's avatar
drew cimino committed
638

639 640
Scripts specified in `before_script` are concatenated with any scripts specified
in the main [`script`](#script), and executed together in a single shell.
641

642
It's possible to overwrite a globally defined `before_script` if you define it in a job:
643 644

```yaml
645 646
default:
  before_script:
647
    - echo "Execute this script in all jobs that don't already have a before_script section."
648

649
job1:
650
  script:
651
    - echo "This script executes after the global before_script."
652 653 654

job:
  before_script:
655
    - echo "Execute this script instead of the global before_script."
656
  script:
657
    - echo "This script executes after the job's `before_script`"
658 659
```

660
You can use [YAML anchors with `before_script`](#yaml-anchors-for-scripts).
661

662
#### `after_script`
663

664 665
`after_script` is used to define an array of commands that run after each job,
including failed jobs.
666

667 668 669
If a job times out or is cancelled, the `after_script` commands are not executed.
Support for executing `after_script` commands for timed-out or cancelled jobs
[is planned](https://gitlab.com/gitlab-org/gitlab/-/issues/15603).
670

671 672
Scripts specified in `after_script` are executed in a new shell, separate from any
`before_script` or `script` scripts. As a result, they:
673

674 675 676 677 678 679 680 681 682
- Have a current working directory set back to the default.
- Have no access to changes done by scripts defined in `before_script` or `script`, including:
  - Command aliases and variables exported in `script` scripts.
  - Changes outside of the working tree (depending on the runner executor), like
    software installed by a `before_script` or `script` script.
- Have a separate timeout, which is hard coded to 5 minutes. See the
  [related issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2716) for details.
- Don't affect the job's exit code. If the `script` section succeeds and the
  `after_script` times out or fails, the job exits with code `0` (`Job Succeeded`).
683 684

```yaml
685 686
default:
  after_script:
687
    - echo "Execute this script in all jobs that don't already have an after_script section."
688

689
job1:
690
  script:
691
    - echo "This script executes first. When it completes, the global after_script executes."
692 693 694

job:
  script:
695
    - echo "This script executes first. When it completes, the job's `after_script` executes."
696
  after_script:
697
    - echo "Execute this script instead of the global after_script."
698 699
```

700
You can use [YAML anchors with `after_script`](#yaml-anchors-for-scripts).
701

702
#### Script syntax
703

704
You can use special syntax in [`script`](README.md#script) sections to:
705

706 707
- [Split long commands](script.md#split-long-commands) into multiline commands.
- [Use color codes](script.md#add-color-codes-to-script-output) to make job logs easier to review.
708
- [Create custom collapsible sections](../jobs/index.md#custom-collapsible-sections)
709
  to simplify job log output.
710

711
### `stage`
712

713
`stage` is defined per-job and relies on [`stages`](#stages), which is defined
714
globally. Use `stage` to define which stage a job runs in, and jobs of the same
715
`stage` are executed in parallel (subject to [certain conditions](#using-your-own-runners)). For example:
716

717 718 719 720 721
```yaml
stages:
  - build
  - test
  - deploy
722

723 724 725
job 0:
  stage: .pre
  script: make something useful before build stage
726

727 728 729
job 1:
  stage: build
  script: make build dependencies
730

731 732 733
job 2:
  stage: build
  script: make build artifacts
734

735 736 737
job 3:
  stage: test
  script: make test
738

739 740 741
job 4:
  stage: deploy
  script: make deploy
742

743 744 745
job 5:
  stage: .post
  script: make something useful at the end of pipeline
746 747
```

Suzanne Selhorn's avatar
Suzanne Selhorn committed
748
#### Using your own runners
749

Suzanne Selhorn's avatar
Suzanne Selhorn committed
750 751 752
When you use your own runners, GitLab Runner runs only one job at a time by default. See the
`concurrent` flag in [runner global settings](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section)
for more information.
753

Suzanne Selhorn's avatar
Suzanne Selhorn committed
754
Jobs run on your own runners in parallel only if:
755

Suzanne Selhorn's avatar
Suzanne Selhorn committed
756 757
- Run on different runners.
- The runner's `concurrent` setting has been changed.
758

759
#### `.pre` and `.post`
760

761
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31441) in GitLab 12.4.
762

763
The following stages are available to every pipeline:
764

765 766
- `.pre`, which is guaranteed to always be the first stage in a pipeline.
- `.post`, which is guaranteed to always be the last stage in a pipeline.
767

768
User-defined stages are executed after `.pre` and before `.post`.
769

770 771
A pipeline is not created if all jobs are in `.pre` or `.post` stages.

Marcel Amirault's avatar
Marcel Amirault committed
772
The order of `.pre` and `.post` can't be changed, even if defined out of order in `.gitlab-ci.yml`.
773
For example, the following are equivalent configuration:
774

775
- Configured in order:
776

777
  ```yaml
778 779 780 781 782 783
  stages:
    - .pre
    - a
    - b
    - .post
  ```
784

785
- Configured out of order:
786

787
  ```yaml
788 789 790 791 792 793
  stages:
    - a
    - .pre
    - b
    - .post
  ```
794

795
- Not explicitly configured:
796

797
  ```yaml
798 799 800 801
  stages:
    - a
    - b
  ```
802

803
### `extends`
804

805
> Introduced in GitLab 11.3.
806

807 808
`extends` defines entry names that a job that uses `extends`
inherits from.
809

Marcel Amirault's avatar
Marcel Amirault committed
810
It's an alternative to using [YAML anchors](#anchors) and is a little
811
more flexible and readable:
812

813 814 815 816 817 818 819
```yaml
.tests:
  script: rake test
  stage: test
  only:
    refs:
      - branches
820

821 822 823 824 825 826 827
rspec:
  extends: .tests
  script: rake rspec
  only:
    variables:
      - $RSPEC
```
828

829
In the example above, the `rspec` job inherits from the `.tests` template job.
830
GitLab performs a reverse deep merge based on the keys. GitLab:
831

832 833
- Merges the `rspec` contents into `.tests` recursively.
- Doesn't merge the values of the keys.
834

835
The result is this `rspec` job, where `script: rake test` is overwritten by `script: rake rspec`:
836 837 838 839 840 841 842 843 844 845 846 847

```yaml
rspec:
  script: rake rspec
  stage: test
  only:
    refs:
      - branches
    variables:
      - $RSPEC
```

848
If you do want to include the `rake test`, see [`before_script`](#before_script) or [`after_script`](#after_script).
849

850
`.tests` in this example is a [hidden job](#hide-jobs), but it's
851 852
possible to inherit from regular jobs as well.

853 854
`extends` supports multi-level inheritance. You should avoid using more than three levels,
but you can use as many as eleven. The following example has two levels of inheritance:
855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880

```yaml
.tests:
  only:
    - pushes

.rspec:
  extends: .tests
  script: rake rspec

rspec 1:
  variables:
    RSPEC_SUITE: '1'
  extends: .rspec

rspec 2:
  variables:
    RSPEC_SUITE: '2'
  extends: .rspec

spinach:
  extends: .tests
  script: rake spinach
```

In GitLab 12.0 and later, it's also possible to use multiple parents for
881 882 883 884 885 886
`extends`.

#### Merge details

`extends` is able to merge hashes but not arrays.
The algorithm used for merge is "closest scope wins", so
887
keys from the last member always override anything defined on other
888 889 890 891
levels. For example:

```yaml
.only-important:
892 893 894
  variables:
    URL: "http://my-url.internal"
    IMPORTANT_VAR: "the details"
895 896 897 898 899
  only:
    - master
    - stable
  tags:
    - production
900 901
  script:
    - echo "Hello world!"
902 903

.in-docker:
904 905
  variables:
    URL: "http://docker-url.internal"
906 907 908 909 910
  tags:
    - docker
  image: alpine

rspec:
911 912
  variables:
    GITLAB: "is-awesome"
913 914 915 916 917 918 919
  extends:
    - .only-important
    - .in-docker
  script:
    - rake rspec
```

920
The result is this `rspec` job:
921 922 923

```yaml
rspec:
924 925 926 927
  variables:
    URL: "http://docker-url.internal"
    IMPORTANT_VAR: "the details"
    GITLAB: "is-awesome"
928 929 930 931 932 933 934 935 936 937
  only:
    - master
    - stable
  tags:
    - docker
  image: alpine
  script:
    - rake rspec
```

938 939 940 941 942 943 944 945 946
Note that in the example above:

- `variables` sections have been merged but that `URL: "http://my-url.internal"`
has been overwritten by `URL: "http://docker-url.internal"`.
- `tags: ['production']` has been overwritten by `tags: ['docker']`.
- `script` has not been merged but rather `script: ['echo "Hello world!"']` has
  been overwritten by `script: ['rake rspec']`. Arrays can be
  merged using [YAML anchors](#anchors).

947 948 949 950 951 952 953 954 955 956 957 958
#### Using `extends` and `include` together

`extends` works across configuration files combined with `include`.

For example, if you have a local `included.yml` file:

```yaml
.template:
  script:
    - echo Hello!
```

959
Then, in `.gitlab-ci.yml`:
960 961 962 963 964 965 966 967 968

```yaml
include: included.yml

useTemplate:
  image: alpine
  extends: .template
```

969
This example runs a job called `useTemplate` that runs `echo Hello!` as defined in
970 971 972 973
the `.template` job, and uses the `alpine` Docker image as defined in the local job.

### `rules`

Marcel Amirault's avatar
Marcel Amirault committed
974
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3.
975

976
The `rules` keyword can be used to include or exclude jobs in pipelines.
977

978 979 980
Rules are evaluated *in order* until the first match. When matched, the job
is either included or excluded from the pipeline, depending on the configuration.
If included, the job also has [certain attributes](#rules-attributes)
981
added to it.
982

983 984
`rules` replaces [`only/except`](#onlyexcept-basic) and can't be used in conjunction with it.
If you attempt to use both keywords in the same job, the linter returns a
985 986
`key may not be used with rules` error.

987
#### Rules attributes
988

989
The job attributes you can use with `rules` are:
990

991 992 993 994
- [`when`](#when): If not defined, defaults to `when: on_success`.
  - If used as `when: delayed`, `start_in` is also required.
- [`allow_failure`](#allow_failure): If not defined, defaults to `allow_failure: false`.

995
If a rule evaluates to true, and `when` has any value except `never`, the job is included in the pipeline.
996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014

For example:

```yaml
docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'
      when: delayed
      start_in: '3 hours'
      allow_failure: true
```

Additional job configuration may be added to rules in the future. If something
useful is not available, please [open an issue](https://gitlab.com/gitlab-org/gitlab/-/issues).

#### Rules clauses

Available rule clauses are:
1015

1016 1017 1018 1019 1020
| Clause                     | Description                                                                                                                        |
|----------------------------|------------------------------------------------------------------------------------------------------------------------------------|
| [`if`](#rulesif)           | Add or exclude jobs from a pipeline by evaluating an `if` statement. Similar to [`only:variables`](#onlyvariablesexceptvariables). |
| [`changes`](#ruleschanges) | Add or exclude jobs from a pipeline based on what files are changed. Same as [`only:changes`](#onlychangesexceptchanges).          |
| [`exists`](#rulesexists)   | Add or exclude jobs from a pipeline based on the presence of specific files.                                                       |
1021

1022 1023 1024
Rules are evaluated in order until a match is found. If a match is found, the attributes
are checked to see if the job should be added to the pipeline. If no attributes are defined,
the defaults are:
1025

1026 1027
- `when: on_success`
- `allow_failure: false`
1028

1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041
The job is added to the pipeline:

- If a rule matches and has `when: on_success`, `when: delayed` or `when: always`.
- If no rules match, but the last clause is `when: on_success`, `when: delayed`
  or `when: always` (with no rule).

The job is not added to the pipeline:

- If no rules match, and there is no standalone `when: on_success`, `when: delayed` or
  `when: always`.
- If a rule matches, and has `when: never` as the attribute.

For example, using `if` clauses to strictly limit when jobs run:
1042 1043 1044

```yaml
job:
1045
  script: echo "Hello, Rules!"
1046
  rules:
1047
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
1048
      when: manual
1049 1050 1051 1052 1053 1054 1055 1056 1057 1058
      allow_failure: true
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
```

In this example:

- If the pipeline is for a merge request, the first rule matches, and the job
  is added to the [merge request pipeline](../merge_request_pipelines/index.md)
  with attributes of:
  - `when: manual` (manual job)
1059
  - `allow_failure: true` (the pipeline continues running even if the manual job is not run)
1060 1061 1062
- If the pipeline is **not** for a merge request, the first rule doesn't match, and the
  second rule is evaluated.
- If the pipeline is a scheduled pipeline, the second rule matches, and the job
1063
  is added to the scheduled pipeline. No attributes were defined, so it is added
1064 1065 1066 1067 1068 1069 1070 1071 1072 1073
  with:
  - `when: on_success` (default)
  - `allow_failure: false` (default)
- In **all other cases**, no rules match, so the job is **not** added to any other pipeline.

Alternatively, you can define a set of rules to exclude jobs in a few cases, but
run them in all other cases:

```yaml
job:
1074
  script: echo "Hello, Rules!"
1075 1076 1077 1078 1079
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: never
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
      when: never
1080 1081 1082
    - when: on_success
```

1083 1084 1085 1086
- If the pipeline is for a merge request, the job is **not** be added to the pipeline.
- If the pipeline is a scheduled pipeline, the job is **not** be added to the pipeline.
- In **all other cases**, the job is added to the pipeline, with `when: on_success`.

1087
CAUTION: **Caution:**
1088
If you use a `when:` clause as the final rule (not including `when: never`), two
1089 1090
simultaneous pipelines may start. Both push pipelines and merge request pipelines can
be triggered by the same event (a push to the source branch for an open merge request).
1091
See how to [prevent duplicate pipelines](#prevent-duplicate-pipelines)
1092 1093
for more details.

1094
#### Prevent duplicate pipelines
1095

1096 1097
Jobs defined with `rules` can trigger multiple pipelines with the same action. You
don't have to explicitly configure rules for each type of pipeline to trigger them
1098 1099
accidentally. Rules that are too broad could cause simultaneous pipelines of a different
type to run unexpectedly.
1100

1101 1102 1103
Some configurations that have the potential to cause duplicate pipelines cause a
[pipeline warning](../troubleshooting.md#pipeline-warnings) to be displayed.
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/219431) in GitLab 13.3.
1104 1105 1106 1107 1108

For example:

```yaml
job:
1109
  script: echo "This job creates double pipelines!"
1110 1111 1112 1113 1114 1115 1116 1117 1118
  rules:
    - if: '$CUSTOM_VARIABLE == "false"'
      when: never
    - when: always
```

This job does not run when `$CUSTOM_VARIABLE` is false, but it *does* run in **all**
other pipelines, including **both** push (branch) and merge request pipelines. With
this configuration, every push to an open merge request's source branch
1119
causes duplicated pipelines.
1120

1121
There are multiple ways to avoid duplicate pipelines:
1122

1123
- Use [`workflow: rules`](#workflowrules) to specify which types of pipelines
1124 1125
  can run. To eliminate duplicate pipelines, use merge request pipelines only
  or push (branch) pipelines only.
1126

1127 1128 1129 1130 1131
- Rewrite the rules to run the job only in very specific cases,
  and avoid using a final `when:` rule:

  ```yaml
  job:
1132
    script: echo "This job does NOT create double pipelines!"
1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145
    rules:
      - if: '$CUSTOM_VARIABLE == "true" && $CI_PIPELINE_SOURCE == "merge_request_event"'
  ```

You can prevent duplicate pipelines by changing the job rules to avoid either push (branch)
pipelines or merge request pipelines. However, if you use a `- when: always` rule without
`workflow: rules`, GitLab still displays a [pipeline warning](../troubleshooting.md#pipeline-warnings).

For example, the following does not trigger double pipelines, but is not recommended
without `workflow: rules`:

```yaml
job:
1146
  script: echo "This job does NOT create double pipelines!"
1147 1148 1149 1150 1151 1152 1153 1154 1155 1156
  rules:
    - if: '$CI_PIPELINE_SOURCE == "push"'
      when: never
    - when: always
```

Do not include both push and merge request pipelines in the same job:

```yaml
job:
1157
  script: echo "This job creates double pipelines!"
1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168
  rules:
    - if: '$CI_PIPELINE_SOURCE == "push"'
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
```

Also, do not mix `only/except` jobs with `rules` jobs in the same pipeline.
It may not cause YAML errors, but the different default behaviors of `only/except`
and `rules` can cause issues that are difficult to troubleshoot:

```yaml
job-with-no-rules:
1169
  script: echo "This job runs in branch pipelines."
1170 1171

job-with-rules:
1172
  script: echo "This job runs in merge request pipelines."
1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
```

For every change pushed to the branch, duplicate pipelines run. One
branch pipeline runs a single job (`job-with-no-rules`), and one merge request pipeline
runs the other job (`job-with-rules`). Jobs with no rules default
to [`except: merge_requests`](#onlyexcept-basic), so `job-with-no-rules`
runs in all cases except merge requests.

It is not possible to define rules based on whether or not a branch has an open
merge request associated with it. You can't configure a job to be included in:

- Only branch pipelines when the branch doesn't have a merge request associated with it.
- Only merge request pipelines when the branch has a merge request associated with it.

See the [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) for more details.
1190

1191
#### `rules:if`
1192 1193

`rules:if` clauses determine whether or not jobs are added to a pipeline by evaluating
1194
an `if` statement. If the `if` statement is true, the job is either included
1195 1196 1197 1198
or excluded from a pipeline. In plain English, `if` rules can be interpreted as one of:

- "If this rule evaluates to true, add the job" (default).
- "If this rule evaluates to true, do not add the job" (by adding `when: never`).
1199 1200

`rules:if` differs slightly from `only:variables` by accepting only a single
1201
expression string per rule, rather than an array of them. Any set of expressions to be
1202 1203
evaluated can be [conjoined into a single expression](../variables/README.md#conjunction--disjunction)
by using `&&` or `||`, and use
1204
the [variable matching syntax](../variables/README.md#syntax-of-environment-variable-expressions).
1205 1206
Unlike variables in [`script`](../variables/README.md#syntax-of-environment-variables-in-job-scripts)
sections, variables in rules expressions are always formatted as `$VARIABLE`.
1207

1208 1209 1210
`if:` clauses are evaluated based on the values of [predefined environment variables](../variables/predefined_variables.md)
or [custom environment variables](../variables/README.md#custom-environment-variables).

1211 1212 1213 1214
For example:

```yaml
job:
1215
  script: echo "Hello, Rules!"
1216
  rules:
1217
    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
1218
      when: always
1219
    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/'
1220
      when: manual
1221
      allow_failure: true
Marcel Amirault's avatar
Marcel Amirault committed
1222
    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME'  # Checking for the presence of a variable is possible
1223 1224
```

1225 1226
Some details regarding the logic that determines the `when` for the job:

1227
- If none of the provided rules match, the job is set to `when: never` and is
1228 1229 1230
  not included in the pipeline.
- A rule without any conditional clause, such as a `when` or `allow_failure`
  rule without `if` or `changes`, always matches, and is always used if reached.
1231
- If a rule matches and has no `when` defined, the rule uses the `when`
1232
  defined for the job, which defaults to `on_success` if not defined.
1233 1234
- You can define `when` once per rule, or once at the job-level, which applies to
  all rules. You can't mix `when` at the job-level with `when` in rules.
1235

1236 1237
##### Common `if` clauses for `rules`

1238
For behavior similar to the [`only`/`except` keywords](#onlyexcept-basic), you can
1239
check the value of the `$CI_PIPELINE_SOURCE` variable:
1240

1241 1242 1243 1244
| Value                         | Description                                                                                                                                                                                                                      |
|-------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `api`                         | For pipelines triggered by the [pipelines API](../../api/pipelines.md#create-a-new-pipeline).                                                                                                                                    |
| `chat`                        | For pipelines created by using a [GitLab ChatOps](../chatops/README.md) command.                                                                                                                                                 |
1245
| `external`                    | When using CI services other than GitLab.                                                                                                                                                                                        |
1246
| `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests).                                            |
1247
| `merge_request_event`         | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). |
1248
| `parent_pipeline`             | For pipelines triggered by a [parent/child pipeline](../parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline.                |
1249 1250 1251 1252 1253 1254
| `pipeline`                    | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#triggering-multi-project-pipelines-through-api), or the [`trigger`](#trigger) keyword. |
| `push`                        | For pipelines triggered by a `git push` event, including for branches and tags.                                                                                                                                                  |
| `schedule`                    | For [scheduled pipelines](../pipelines/schedules.md).                                                                                                                                                                            |
| `trigger`                     | For pipelines created by using a [trigger token](../triggers/README.md#trigger-token).                                                                                                                                           |
| `web`                         | For pipelines created by using **Run pipeline** button in the GitLab UI, from the project's **CI/CD > Pipelines** section.                                                                                                       |
| `webide`                      | For pipelines created by using the [WebIDE](../../user/project/web_ide/index.md).                                                                                                                                                |
1255 1256 1257 1258 1259

For example:

```yaml
job:
1260
  script: echo "Hello, Rules!"
1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
      when: manual
      allow_failure: true
    - if: '$CI_PIPELINE_SOURCE == "push"'
```

This example runs the job as a manual job in scheduled pipelines or in push
pipelines (to branches or tags), with `when: on_success` (default). It does not
add the job to any other pipeline type.

Another example:

```yaml
job:
1276
  script: echo "Hello, Rules!"
1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
```

This example runs the job as a `when: on_success` job in [merge request pipelines](../merge_request_pipelines/index.md)
and scheduled pipelines. It does not run in any other pipeline type.

Other commonly used variables for `if` clauses:

- `if: $CI_COMMIT_TAG`: If changes are pushed for a tag.
- `if: $CI_COMMIT_BRANCH`: If changes are pushed to any branch.
- `if: '$CI_COMMIT_BRANCH == "master"'`: If changes are pushed to `master`.
- `if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'`: If changes are pushed to the default
1291 1292
  branch (usually `master`). Use when you want to have the same configuration in multiple
  projects with different default branches.
1293 1294 1295 1296 1297
- `if: '$CI_COMMIT_BRANCH =~ /regex-expression/'`: If the commit branch matches a regular expression.
- `if: '$CUSTOM_VARIABLE !~ /regex-expression/'`: If the [custom variable](../variables/README.md#custom-environment-variables)
  `CUSTOM_VARIABLE` does **not** match a regular expression.
- `if: '$CUSTOM_VARIABLE == "value1"'`: If the custom variable `CUSTOM_VARIABLE` is
  exactly `value1`.
1298

1299
#### `rules:changes`
1300

1301 1302
`rules:changes` determines whether or not to add jobs to a pipeline by checking for
changes to specific files.
1303 1304

`rules: changes` works exactly the same way as [`only: changes` and `except: changes`](#onlychangesexceptchanges),
1305 1306 1307
accepting an array of paths. It's recommended to only use `rules: changes` with branch
pipelines or merge request pipelines. For example, it's common to use `rules: changes`
with merge request pipelines:
1308 1309 1310 1311 1312

```yaml
docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
1313 1314
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
1315
        - Dockerfile
1316
      when: manual
1317
      allow_failure: true
1318 1319
```

1320
In this example:
1321

1322
- If the pipeline is a merge request pipeline, check `Dockerfile` for changes.
1323 1324
- If `Dockerfile` has changed, add the job to the pipeline as a manual job, and the pipeline
  continues running even if the job is not triggered (`allow_failure: true`).
1325
- If `Dockerfile` has not changed, do not add job to any pipeline (same as `when: never`).
1326

1327 1328 1329 1330 1331 1332 1333 1334 1335
To use `rules: changes` with branch pipelines instead of merge request pipelines,
change the `if:` clause in the example above to:

```yaml
rules:
  - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH
```

To implement a rule similar to [`except:changes`](#onlychangesexceptchanges),
Ben Bodenmiller's avatar
Ben Bodenmiller committed
1336 1337
use `when: never`.

1338 1339 1340 1341 1342 1343 1344
CAUTION: **Caution:**
You can use `rules: changes` with other pipeline types, but it is not recommended
because `rules: changes` always evaluates to true when there is no Git `push` event.
Tag pipelines, scheduled pipelines, and so on do **not** have a Git `push` event
associated with them. A `rules: changes` job is **always** added to those pipeline
if there is no `if:` statement that limits the job to branch or merge request pipelines.

1345 1346 1347
##### Variables in `rules:changes`

> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34272) in GitLab 13.6.
1348
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/267192) in GitLab 13.7.
1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366

Environment variables can be used in `rules:changes` expressions to determine when
to add jobs to a pipeline:

```yaml
docker build:
  variables:
    DOCKERFILES_DIR: 'path/to/files/'
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - changes:
        - $DOCKERFILES_DIR/*
```

The `$` character can be used for both variables and paths. For example, if the
`$DOCKERFILES_DIR` variable exists, its value is used. If it does not exist, the
`$` is interpreted as being part of a path.

1367
#### `rules:exists`
James Fargher's avatar
James Fargher committed
1368

Marcel Amirault's avatar
Marcel Amirault committed
1369
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24021) in GitLab 12.4.
1370

1371
`exists` accepts an array of paths and matches if any of these paths exist
1372
as files in the repository:
James Fargher's avatar
James Fargher committed
1373 1374 1375 1376 1377 1378

```yaml
job:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - exists:
1379
        - Dockerfile
James Fargher's avatar
James Fargher committed
1380 1381
```

1382
You can also use glob patterns to match multiple files in any directory in the repository:
James Fargher's avatar
James Fargher committed
1383 1384 1385 1386 1387 1388

```yaml
job:
  script: bundle exec rspec
  rules:
    - exists:
1389
        - spec/**.rb
James Fargher's avatar
James Fargher committed
1390 1391
```

1392 1393
For performance reasons, using `exists` with patterns is limited to 10,000
checks. After the 10,000th check, rules with patterned globs always match.
James Fargher's avatar
James Fargher committed
1394

1395
#### `rules:allow_failure`
1396

1397
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30235) in GitLab 12.8.
1398

1399
You can use [`allow_failure: true`](#allow_failure) in `rules:` to allow a job to fail, or a manual job to
1400 1401 1402
wait for action, without stopping the pipeline itself. All jobs using `rules:` default to `allow_failure: false`
if `allow_failure:` is not defined.

1403 1404 1405 1406
The rule-level `rules:allow_failure` option overrides the job-level
[`allow_failure`](#allow_failure) option, and is only applied when the job is
triggered by the particular rule.

1407 1408
```yaml
job:
1409
  script: echo "Hello, Rules!"
1410 1411 1412 1413 1414 1415
  rules:
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
      when: manual
      allow_failure: true
```

1416
In this example, if the first rule matches, then the job has `when: manual` and `allow_failure: true`.
1417

1418
#### Complex rule clauses
1419

1420
To conjoin `if`, `changes`, and `exists` clauses with an `AND`, use them in the
James Fargher's avatar
James Fargher committed
1421
same rule.
1422 1423 1424

In the following example:

1425
- If the `Dockerfile` file or any file in `/docker/scripts` has changed, and var=blah,
1426 1427
  then the job runs manually
- Otherwise, the job isn't included in the pipeline.
1428 1429 1430 1431 1432 1433

```yaml
docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: '$VAR == "string value"'
1434
      changes:  # Include the job and set to when:manual if any of the follow paths match a modified file.
1435 1436
        - Dockerfile
        - docker/scripts/*
1437
      when: manual
1438
      # - "when: never" would be redundant here. It is implied any time rules are listed.
1439 1440
```

1441 1442
Keywords such as `branches` or `refs` that are available for
`only`/`except` are not available in `rules`. They are being individually
1443 1444 1445
considered for their usage and behavior in this context. Future keyword improvements
are being discussed in our [epic for improving `rules`](https://gitlab.com/groups/gitlab-org/-/epics/2783),
where anyone can add suggestions or requests.
1446

1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457
You can use [parentheses](../variables/README.md#parentheses) with `&&` and `||` to build more complicated variable expressions.
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230938) in GitLab 13.3:

```yaml
job1:
  script:
    - echo This rule uses parentheses.
  rules:
    if: ($CI_COMMIT_BRANCH == "master" || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE
```

1458
CAUTION: **Caution:**
1459 1460
[Before GitLab 13.3](https://gitlab.com/gitlab-org/gitlab/-/issues/230938),
rules that use both `||` and `&&` may evaluate with an unexpected order of operations.
1461

1462
### `only`/`except` (basic)
1463

1464
NOTE: **Note:**
1465 1466 1467
The [`rules`](#rules) syntax is an improved, more powerful solution for defining
when jobs should run or not. Consider using `rules` instead of `only/except` to get
the most out of your pipelines.
1468

1469
`only` and `except` are two keywords that set a job policy to limit when
1470
jobs are created:
1471

1472 1473 1474
1. `only` defines the names of branches and tags the job runs for.
1. `except` defines the names of branches and tags the job does
    **not** run for.
1475

1476
There are a few rules that apply to the usage of job policy:
1477

1478 1479
- `only` and `except` are inclusive. If both `only` and `except` are defined
   in a job specification, the ref is filtered by `only` and `except`.
1480 1481
- `only` and `except` can use regular expressions ([supported regexp syntax](#supported-onlyexcept-regexp-syntax)).
- `only` and `except` can specify a repository path to filter jobs for forks.
1482

1483
In addition, `only` and `except` can use special keywords:
1484

1485 1486 1487
| **Value**                | **Description**                                                                                                                                                                                                                  |
|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `api`                    | For pipelines triggered by the [pipelines API](../../api/pipelines.md#create-a-new-pipeline).                                                                                                                                    |
1488 1489
| `branches`               | When the Git reference for a pipeline is a branch.                                                                                                                                                                               |
| `chat`                   | For pipelines created by using a [GitLab ChatOps](../chatops/README.md) command.                                                                                                                                                 |
1490
| `external`               | When using CI services other than GitLab.                                                                                                                                                                                        |
1491 1492
| `external_pull_requests` | When an external pull request on GitHub is created or updated (See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests)).                                           |
| `merge_requests`         | For pipelines created when a merge request is created or updated. Enables [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). |
1493 1494 1495
| `pipelines`              | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#triggering-multi-project-pipelines-through-api), or the [`trigger`](#trigger) keyword. |
| `pushes`                 | For pipelines triggered by a `git push` event, including for branches and tags.                                                                                                                                                  |
| `schedules`              | For [scheduled pipelines](../pipelines/schedules.md).                                                                                                                                                                            |
1496
| `tags`                   | When the Git reference for a pipeline is a tag.                                                                                                                                                                                  |
1497 1498
| `triggers`               | For pipelines created by using a [trigger token](../triggers/README.md#trigger-token).                                                                                                                                           |
| `web`                    | For pipelines created by using **Run pipeline** button in the GitLab UI, from the project's **CI/CD > Pipelines** section.                                                                                                       |
1499

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1500 1501
In the example below, `job` runs only for refs that start with `issue-`,
whereas all branches are skipped:
1502 1503

```yaml
1504
job:
1505 1506 1507 1508 1509 1510 1511
  # use regexp
  only:
    - /^issue-.*$/
  # use special keyword
  except:
    - branches
```
1512

1513 1514
Pattern matching is case-sensitive by default. Use `i` flag modifier, like
`/pattern/i` to make a pattern case-insensitive:
1515 1516

```yaml
1517 1518 1519 1520 1521 1522 1523
job:
  # use regexp
  only:
    - /^issue-.*$/i
  # use special keyword
  except:
    - branches
1524 1525
```

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1526 1527
In this example, `job` runs only for refs that are tagged, or if a build is
explicitly requested by an API trigger or a [Pipeline Schedule](../pipelines/schedules.md):
1528 1529

```yaml
1530 1531 1532 1533 1534 1535
job:
  # use special keywords
  only:
    - tags
    - triggers
    - schedules
1536 1537
```

1538 1539
The repository path can be used to have jobs executed only for the parent
repository and not forks:
1540 1541

```yaml
1542 1543 1544 1545 1546 1547
job:
  only:
    - branches@gitlab-org/gitlab
  except:
    - master@gitlab-org/gitlab
    - /^release/.*$/@gitlab-org/gitlab
1548 1549
```

1550
The above example runs `job` for all branches on `gitlab-org/gitlab`,
1551
except `master` and those with names prefixed with `release/`.
1552

1553
If a job does not have an `only` rule, `only: ['branches', 'tags']` is set by
Marcel Amirault's avatar
Marcel Amirault committed
1554
default. If it does not have an `except` rule, it's empty.
1555

1556
For example,
1557

1558 1559 1560 1561
```yaml
job:
  script: echo 'test'
```
1562

1563
is translated to:
1564 1565

```yaml
1566 1567 1568
job:
  script: echo 'test'
  only: ['branches', 'tags']
1569 1570
```

1571
#### Regular expressions
1572

1573 1574 1575
The `@` symbol denotes the beginning of a ref's repository path.
To match a ref name that contains the `@` character in a regular expression,
you must use the hex character code match `\x40`.
1576

1577 1578
Only the tag or branch name can be matched by a regular expression.
The repository path, if given, is always matched literally.
1579

1580 1581 1582 1583 1584 1585
To match the tag or branch name,
the entire ref name part of the pattern must be a regular expression surrounded by `/`.
For example, you can't use `issue-/.*/` to match all tag names or branch names
that begin with `issue-`, but you can use `/issue-.*/`.

Regular expression flags must be appended after the closing `/`.
1586

1587
TIP: **Tip:**
1588 1589 1590 1591
Use anchors `^` and `$` to avoid the regular expression
matching only a substring of the tag name or branch name.
For example, `/^issue-.*$/` is equivalent to `/^issue-/`,
while just `/issue/` would also match a branch called `severe-issues`.
1592

1593
#### Supported `only`/`except` regexp syntax
1594

1595
In GitLab 11.9.4, GitLab began internally converting the regexp used
1596
in `only` and `except` keywords to [RE2](https://github.com/google/re2/wiki/Syntax).
1597

1598 1599 1600 1601
[RE2](https://github.com/google/re2/wiki/Syntax) limits the set of available features
due to computational complexity, and some features, like negative lookaheads, became unavailable.
Only a subset of features provided by [Ruby Regexp](https://ruby-doc.org/core/Regexp.html)
are now supported.
1602

1603
From GitLab 11.9.7 to GitLab 12.0, GitLab provided a feature flag to
1604 1605
let you use unsafe regexp syntax. After migrating to safe syntax, you should disable
this feature flag again:
1606

1607 1608 1609
```ruby
Feature.enable(:allow_unsafe_ruby_regexp)
```
1610

1611
### `only`/`except` (advanced)
1612

1613 1614
GitLab supports both simple and complex strategies, so it's possible to use an
array and a hash configuration scheme.
1615

1616
Four keys are available:
1617

1618 1619 1620 1621
- `refs`
- `variables`
- `changes`
- `kubernetes`
1622

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1623
If you use multiple keys under `only` or `except`, the keys are evaluated as a
1624
single conjoined expression. That is:
1625

1626 1627
- `only:` includes the job if **all** of the keys have at least one condition that matches.
- `except:` excludes the job if **any** of the keys have at least one condition that matches.
1628

1629 1630
With `only`, individual keys are logically joined by an `AND`. A job is added to
the pipeline if the following is true:
1631

1632
- `(any listed refs are true) AND (any listed variables are true) AND (any listed changes are true) AND (any chosen Kubernetes status matches)`
1633

1634
In the example below, the `test` job is `only` created when **all** of the following are true:
1635

1636
- The pipeline has been [scheduled](../pipelines/schedules.md) **or** runs for `master`.
1637 1638
- The `variables` keyword matches.
- The `kubernetes` service is active on the project.
1639

1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650
```yaml
test:
  script: npm run test
  only:
    refs:
      - master
      - schedules
    variables:
      - $CI_COMMIT_MESSAGE =~ /run-end-to-end-tests/
    kubernetes: active
```
1651

1652 1653
With `except`, individual keys are logically joined by an `OR`. A job is **not**
added if the following is true:
1654

1655
- `(any listed refs are true) OR (any listed variables are true) OR (any listed changes are true) OR (a chosen Kubernetes status matches)`
1656

1657
In the example below, the `test` job is **not** created when **any** of the following are true:
1658

Jonston Chan's avatar
Jonston Chan committed
1659
- The pipeline runs for the `master` branch.
Marcel Amirault's avatar
Marcel Amirault committed
1660
- There are changes to the `README.md` file in the root directory of the repository.
1661 1662

```yaml
1663 1664 1665 1666 1667 1668 1669
test:
  script: npm run test
  except:
    refs:
      - master
    changes:
      - "README.md"
1670 1671
```

1672
#### `only:refs`/`except:refs`
1673

1674
> `refs` policy introduced in GitLab 10.0.
1675

1676 1677
The `refs` strategy can take the same values as the
[simplified only/except configuration](#onlyexcept-basic).
1678

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1679 1680
In the example below, the `deploy` job is created only when the
pipeline is [scheduled](../pipelines/schedules.md) or runs for the `master` branch:
1681

1682 1683 1684 1685 1686 1687 1688
```yaml
deploy:
  only:
    refs:
      - master
      - schedules
```
1689

1690
#### `only:kubernetes`/`except:kubernetes`
1691

1692
> `kubernetes` policy introduced in GitLab 10.0.
1693

1694
The `kubernetes` strategy accepts only the `active` keyword.
1695

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1696
In the example below, the `deploy` job is created only when the
1697
Kubernetes service is active in the project:
1698 1699

```yaml
1700 1701 1702
deploy:
  only:
    kubernetes: active
1703 1704
```

1705
#### `only:variables`/`except:variables`
1706

1707
> `variables` policy introduced in GitLab 10.7.
1708

1709 1710 1711
The `variables` keyword defines variable expressions.

These expressions determine whether or not a job should be created.
1712

1713
Examples of using variable expressions:
1714

1715 1716 1717 1718 1719 1720 1721 1722 1723 1724
```yaml
deploy:
  script: cap staging deploy
  only:
    refs:
      - branches
    variables:
      - $RELEASE == "staging"
      - $STAGING
```
1725

1726
Another use case is excluding jobs depending on a commit message:
1727 1728

```yaml
1729 1730 1731 1732 1733
end-to-end:
  script: rake test:end-to-end
  except:
    variables:
      - $CI_COMMIT_MESSAGE =~ /skip-end-to-end-tests/
1734 1735
```

1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746
You can use [parentheses](../variables/README.md#parentheses) with `&&` and `||` to build more complicated variable expressions.
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230938) in GitLab 13.3:

```yaml
job1:
  script:
    - echo This rule uses parentheses.
  only:
    variables:
      - ($CI_COMMIT_BRANCH == "master" || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE
```
1747

1748
#### `only:changes`/`except:changes`
1749

1750
> `changes` policy [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/19232) in GitLab 11.4.
1751

1752 1753
Using the `changes` keyword with `only` or `except` makes it possible to define if
a job should be created based on files modified by a Git push event.
1754

1755 1756
Use the `only:changes` policy for pipelines triggered by the following
refs only:
1757

1758 1759 1760
- `branches`
- `external_pull_requests`
- `merge_requests` (see additional details about [using `only:changes` with pipelines for merge requests](#using-onlychanges-with-pipelines-for-merge-requests))
1761

1762 1763 1764
CAUTION: **Caution:**
In pipelines with [sources other than the three above](../variables/predefined_variables.md)
`changes` can't determine if a given file is new or old and always returns `true`.
1765 1766
You can configure jobs to use `only: changes` with other `only: refs` keywords. However,
those jobs ignore the changes and always run.
1767 1768

A basic example of using `only: changes`:
1769 1770

```yaml
1771 1772 1773
docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  only:
1774 1775
    refs:
      - branches
1776 1777 1778 1779 1780
    changes:
      - Dockerfile
      - docker/scripts/*
      - dockerfiles/**/*
      - more_scripts/*.{rb,py,sh}
1781 1782
```

1783 1784
When you push commits to an existing branch,
the `docker build` job is created, but only if changes were made to any of the following:
1785

1786
- The `Dockerfile` file.
1787 1788 1789
- Any of the files in the `docker/scripts/` directory.
- Any of the files and subdirectories in the `dockerfiles` directory.
- Any of the files with `rb`, `py`, `sh` extensions in the `more_scripts` directory.
1790

1791
CAUTION: **Warning:**
1792
If you use `only:changes` with [only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds),
1793
you should [also use `only:merge_requests`](#using-onlychanges-with-pipelines-for-merge-requests). Otherwise it may not work as expected.
1794

1795
You can also use glob patterns to match multiple files in either the root directory
1796
of the repository, or in _any_ directory in the repository. However, they must be wrapped
1797
in double quotes or GitLab can't parse them. For example:
1798

1799 1800 1801 1802
```yaml
test:
  script: npm run test
  only:
1803 1804
    refs:
      - branches
1805 1806 1807 1808
    changes:
      - "*.json"
      - "**/*.sql"
```
1809

1810 1811
You can skip a job if a change is detected in any file with a
`.md` extension in the root directory of the repository:
1812

1813 1814 1815 1816 1817 1818 1819 1820
```yaml
build:
  script: npm run build
  except:
    changes:
      - "*.md"
```

1821 1822
If you change multiple files, but only one file ends in `.md`,
the `build` job is still skipped. The job does not run for any of the files.
1823

1824 1825 1826 1827
Read more about how to use this feature with:

- [New branches or tags *without* pipelines for merge requests](#using-onlychanges-without-pipelines-for-merge-requests).
- [Scheduled pipelines](#using-onlychanges-with-scheduled-pipelines).
1828

1829
##### Using `only:changes` with pipelines for merge requests
1830

1831
With [pipelines for merge requests](../merge_request_pipelines/index.md),
Marcel Amirault's avatar
Marcel Amirault committed
1832
it's possible to define a job to be created based on files modified
1833
in a merge request.
1834

1835 1836 1837
Use this keyword with `only: [merge_requests]` so GitLab can find the correct base
SHA of the source branch. File differences are correctly calculated from any further
commits, and all changes in the merge requests are properly tested in pipelines.
1838

1839
For example:
1840 1841

```yaml
1842 1843 1844 1845 1846 1847 1848 1849
docker build service one:
  script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
  only:
    refs:
      - merge_requests
    changes:
      - Dockerfile
      - service-one/**/*
1850 1851
```

1852 1853 1854
In this scenario, if a merge request changes
files in the `service-one` directory or the `Dockerfile`, GitLab creates
the `docker build service one` job.
1855

1856 1857 1858 1859 1860 1861 1862 1863 1864
For example:

```yaml
docker build service one:
  script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
  only:
    changes:
      - Dockerfile
      - service-one/**/*
1865 1866
```

1867
In the example above, the pipeline might fail because of changes to a file in `service-one/**/*`.
1868

1869 1870 1871 1872 1873 1874 1875 1876 1877
A later commit that doesn't have changes in `service-one/**/*`
but does have changes to the `Dockerfile` can pass. The job
only tests the changes to the `Dockerfile`.

GitLab checks the **most recent pipeline** that **passed**. If the merge request is mergeable,
it doesn't matter that an earlier pipeline failed because of a change that has not been corrected.

When you use this configuration, ensure that the most recent pipeline
properly corrects any failures from previous pipelines.
1878

1879
##### Using `only:changes` without pipelines for merge requests
1880

1881 1882
Without [pipelines for merge requests](../merge_request_pipelines/index.md), pipelines
run on branches or tags that don't have an explicit association with a merge request.
1883 1884
In this case, a previous SHA is used to calculate the diff, which is equivalent to `git diff HEAD~`.
This can result in some unexpected behavior, including:
1885

1886 1887 1888
- When pushing a new branch or a new tag to GitLab, the policy always evaluates to true.
- When pushing a new commit, the changed files are calculated using the previous commit
  as the base SHA.
1889

1890
##### Using `only:changes` with scheduled pipelines
1891

1892 1893 1894
`only:changes` always evaluates as "true" in [Scheduled pipelines](../pipelines/schedules.md).
All files are considered to have "changed" when a scheduled pipeline
runs.
1895

1896
### `needs`
1897

1898
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063) in GitLab 12.2.
1899
> - In GitLab 12.3, maximum number of jobs in `needs` array raised from five to 50.
1900
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30631) in GitLab 12.8, `needs: []` lets jobs start immediately.
1901

1902 1903
Use the `needs:` keyword to execute jobs out-of-order. Relationships between jobs
that use `needs` can be visualized as a [directed acyclic graph](../directed_acyclic_graph/index.md).
1904

1905 1906
You can ignore stage ordering and run some jobs without waiting for others to complete.
Jobs in multiple stages can run concurrently.
1907 1908

Let's consider the following example:
1909 1910

```yaml
1911 1912
linux:build:
  stage: build
1913

1914 1915
mac:build:
  stage: build
1916

1917 1918 1919
lint:
  stage: test
  needs: []
1920

1921 1922 1923
linux:rspec:
  stage: test
  needs: ["linux:build"]
1924

1925 1926 1927
linux:rubocop:
  stage: test
  needs: ["linux:build"]
1928

1929 1930 1931
mac:rspec:
  stage: test
  needs: ["mac:build"]
1932

1933 1934 1935
mac:rubocop:
  stage: test
  needs: ["mac:build"]
1936

1937 1938 1939
production:
  stage: deploy
```
1940

1941
This example creates four paths of execution:
1942

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1943
- Linter: the `lint` job runs immediately without waiting for the `build` stage to complete because it has no needs (`needs: []`).
1944

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1945
- Linux path: the `linux:rspec` and `linux:rubocop` jobs runs as soon
1946
  as the `linux:build` job finishes without waiting for `mac:build` to finish.
1947

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1948
- macOS path: the `mac:rspec` and `mac:rubocop` jobs runs as soon
1949
  as the `mac:build` job finishes, without waiting for `linux:build` to finish.
1950

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1951
- The `production` job runs as soon as all previous jobs
1952 1953
  finish; in this case: `linux:build`, `linux:rspec`, `linux:rubocop`,
  `mac:build`, `mac:rspec`, `mac:rubocop`.
1954

1955
#### Requirements and limitations
1956

1957 1958
- If `needs:` is set to point to a job that is not instantiated
  because of `only/except` rules or otherwise does not exist, the
Suzanne Selhorn's avatar
Suzanne Selhorn committed
1959
  pipeline is not created and a YAML error is shown.
Marcel Amirault's avatar
Marcel Amirault committed
1960
- The maximum number of jobs that a single job can need in the `needs:` array is limited:
1961
  - For GitLab.com, the limit is 50. For more information, see our
Marcel Amirault's avatar
Marcel Amirault committed
1962
    [infrastructure issue](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/7541).
1963
  - For self-managed instances, the limit is: 50. This limit [can be changed](#changing-the-needs-job-limit).
1964
- If `needs:` refers to a job that is marked as `parallel:`.
Suzanne Selhorn's avatar
Suzanne Selhorn committed
1965 1966
  the current job depends on all parallel jobs being created.
- `needs:` is similar to `dependencies:` in that it must use jobs from prior stages,
Marcel Amirault's avatar
Marcel Amirault committed
1967
  meaning it's impossible to create circular dependencies. Depending on jobs in the
1968
  current stage is not possible either, but support [is planned](https://gitlab.com/gitlab-org/gitlab/-/issues/30632).
1969 1970
- Related to the above, stages must be explicitly defined for all jobs
  that have the keyword `needs:` or are referred to by one.
1971

1972
##### Changing the `needs:` job limit **(CORE ONLY)**
1973

1974
The maximum number of jobs that can be defined in `needs:` defaults to 50.
1975

1976 1977
A GitLab administrator with [access to the GitLab Rails console](../../administration/feature_flags.md)
can choose a custom limit. For example, to set the limit to 100:
1978

1979
```ruby
1980
Plan.default.actual_limits.update!(ci_needs_size_limit: 100)
1981 1982
```

1983
To disable directed acyclic graphs (DAG), set the limit to `0`.
1984

1985
#### Artifact downloads with `needs`
1986

1987
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14311) in GitLab v12.6.
1988

1989
When using `needs`, artifact downloads are controlled with `artifacts: true` (default) or `artifacts: false`.
1990

1991
In GitLab 12.6 and later, you can't combine the [`dependencies`](#dependencies) keyword
1992 1993
with `needs` to control artifact downloads in jobs. `dependencies` is still valid
in jobs that do not use `needs`.
1994

Suzanne Selhorn's avatar
Suzanne Selhorn committed
1995 1996
In the example below, the `rspec` job downloads the `build_job` artifacts, while the
`rubocop` job doesn't:
1997

1998
```yaml
1999 2000 2001
build_job:
  stage: build
  artifacts:
2002
    paths:
2003
      - binaries/
2004

2005 2006
rspec:
  stage: test
2007 2008 2009
  needs:
    - job: build_job
      artifacts: true
2010

2011 2012 2013 2014 2015 2016
rubocop:
  stage: test
  needs:
    - job: build_job
      artifacts: false
```
2017

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2018
Additionally, in the three syntax examples below, the `rspec` job downloads the artifacts
2019
from all three `build_jobs`. `artifacts` is true for `build_job_1` and
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2020
**defaults** to true for both `build_job_2` and `build_job_3`.
2021

2022 2023 2024 2025 2026 2027 2028 2029
```yaml
rspec:
  needs:
    - job: build_job_1
      artifacts: true
    - job: build_job_2
    - build_job_3
```
2030

2031
#### Cross project artifact downloads with `needs` **(PREMIUM)**
2032

2033
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14311) in GitLab v12.7.
2034

2035 2036 2037 2038
Use `needs` to download artifacts from up to five jobs in pipelines:

- [On other refs in the same project](#artifact-downloads-between-pipelines-in-the-same-project).
- In different projects, groups and namespaces.
2039

2040 2041 2042 2043 2044 2045
```yaml
build_job:
  stage: build
  script:
    - ls -lhR
  needs:
2046
    - project: namespace/group/project-name
2047 2048 2049 2050
      job: build-1
      ref: master
      artifacts: true
```
2051

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2052
`build_job` downloads the artifacts from the latest successful `build-1` job
2053 2054 2055 2056 2057
on the `master` branch in the `group/project-name` project. If the project is in the
same group or namespace, you can omit them from the `project:` key. For example,
`project: group/project-name` or `project: project-name`.

The user running the pipeline must have at least `reporter` access to the group or project, or the group/project must have public visibility.
2058

2059
##### Artifact downloads between pipelines in the same project
2060

2061 2062 2063 2064
Use `needs` to download artifacts from different pipelines in the current project.
Set the `project` keyword as the current project's name, and specify a ref.

In this example, `build_job` downloads the artifacts for the latest successful
2065
`build-1` job with the `other-ref` ref:
2066

2067
```yaml
2068 2069 2070 2071 2072 2073 2074 2075 2076
build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: group/same-project-name
      job: build-1
      ref: other-ref
      artifacts: true
2077
```
2078

2079
Environment variables support for `project:`, `job:`, and `ref` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202093)
2080
in GitLab 13.3. [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/235761) in GitLab 13.4.
2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095

For example:

```yaml
build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: $CI_PROJECT_PATH
      job: $DEPENDENCY_JOB_NAME
      ref: $CI_COMMIT_BRANCH
      artifacts: true
```

2096 2097 2098 2099
Downloading artifacts from jobs that are run in [`parallel:`](#parallel) is not supported.

### `tags`

2100 2101
Use `tags` to select a specific runner from the list of all runners that are
available for the project.
2102

2103
When you register a runner, you can specify the runner's tags, for
2104 2105
example `ruby`, `postgres`, `development`.

2106
In this example, the job is run by a runner that
2107
has both `ruby` and `postgres` tags defined.
2108 2109 2110

```yaml
job:
2111 2112 2113
  tags:
    - ruby
    - postgres
2114 2115
```

2116 2117 2118
You can use tags to run different jobs on different platforms. For
example, if you have an OS X runner with tag `osx` and a Windows runner with tag
`windows`, you can run a job on each platform:
2119 2120

```yaml
2121 2122 2123 2124 2125
windows job:
  stage:
    - build
  tags:
    - windows
2126
  script:
2127
    - echo Hello, %USERNAME%!
2128

2129 2130 2131 2132 2133
osx job:
  stage:
    - build
  tags:
    - osx
2134
  script:
2135
    - echo "Hello, $USER!"
2136 2137
```

2138
### `allow_failure`
2139

2140
Use `allow_failure` when you want to let a job fail without impacting the rest of the CI
2141 2142 2143 2144
suite.
The default value is `false`, except for [manual](#whenmanual) jobs using the
`when: manual` syntax, unless using [`rules:`](#rules) syntax, where all jobs
default to false, *including* `when: manual` jobs.
2145

2146
When `allow_failure` is set to `true` and the job fails, the job shows an orange warning in the UI.
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2147
However, the logical flow of the pipeline considers the job a
2148
success/passed, and is not blocked.
Evan Read's avatar
Evan Read committed
2149

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2150 2151
Assuming all other jobs are successful, the job's stage and its pipeline
show the same orange warning. However, the associated commit is marked as
2152
"passed", without warnings.
Evan Read's avatar
Evan Read committed
2153

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2154 2155
In the example below, `job1` and `job2` run in parallel, but if `job1`
fails, it doesn't stop the next stage from running, because it's marked with
2156
`allow_failure: true`:
Evan Read's avatar
Evan Read committed
2157

2158 2159 2160 2161 2162 2163
```yaml
job1:
  stage: test
  script:
    - execute_script_that_will_fail
  allow_failure: true
Evan Read's avatar
Evan Read committed
2164

2165 2166 2167 2168 2169 2170 2171 2172 2173
job2:
  stage: test
  script:
    - execute_script_that_will_succeed

job3:
  stage: deploy
  script:
    - deploy_to_staging
Evan Read's avatar
Evan Read committed
2174 2175
```

2176
### `when`
Evan Read's avatar
Evan Read committed
2177

2178 2179
`when` is used to implement jobs that are run in case of failure or despite the
failure.
Evan Read's avatar
Evan Read committed
2180

2181
`when` can be set to one of the following values:
Evan Read's avatar
Evan Read committed
2182

2183 2184 2185 2186 2187 2188 2189
1. `on_success` (default) - Execute job only when all jobs in earlier stages succeed,
    or are considered successful because they have `allow_failure: true`.
1. `on_failure` - Execute job only when at least one job in an earlier stage fails.
1. `always` - Execute job regardless of the status of jobs in earlier stages.
1. `manual` - Execute job [manually](#whenmanual).
1. `delayed` - [Delay the execution of a job](#whendelayed) for a specified duration.
    Added in GitLab 11.14.
Ben Bodenmiller's avatar
Ben Bodenmiller committed
2190 2191 2192
1. `never`:
   - With [`rules`](#rules), don't execute job.
   - With [`workflow:rules`](#workflowrules), don't run pipeline.
Evan Read's avatar
Evan Read committed
2193

2194
For example:
Evan Read's avatar
Evan Read committed
2195

2196 2197 2198 2199 2200 2201 2202
```yaml
stages:
  - build
  - cleanup_build
  - test
  - deploy
  - cleanup
2203

2204 2205 2206 2207
build_job:
  stage: build
  script:
    - make build
2208

2209 2210 2211 2212 2213
cleanup_build_job:
  stage: cleanup_build
  script:
    - cleanup build when failed
  when: on_failure
2214

2215 2216 2217 2218
test_job:
  stage: test
  script:
    - make test
2219

2220 2221 2222 2223 2224
deploy_job:
  stage: deploy
  script:
    - make deploy
  when: manual
2225

2226 2227 2228 2229 2230
cleanup_job:
  stage: cleanup
  script:
    - cleanup after jobs
  when: always
2231 2232
```

2233
The above script:
2234

2235 2236
1. Executes `cleanup_build_job` only when `build_job` fails.
1. Always executes `cleanup_job` as the last step in pipeline regardless of
2237
   success or failure.
2238
1. Executes `deploy_job` when you run it manually in the GitLab UI.
2239

2240
#### `when:manual`
2241

2242 2243
A manual job is a type of job that is not executed automatically and must be explicitly
started by a user. You might want to use manual jobs for things like deploying to production.
2244

2245
To make a job manual, add `when: manual` to its configuration.
2246

2247 2248
Manual jobs can be started from the pipeline, job, [environment](../environments/index.md#configuring-manual-deployments),
and deployment views.
2249

2250
Manual jobs can be either optional or blocking:
2251

2252 2253 2254
- **Optional**: Manual jobs have [`allow_failure: true](#allow_failure) set by default
  and are considered optional. The status of an optional manual job does not contribute
  to the overall pipeline status. A pipeline can succeed even if all its manual jobs fail.
2255

2256 2257 2258 2259
- **Blocking**: To make a blocking manual job, add `allow_failure: false` to its configuration.
  Blocking manual jobs stop further execution of the pipeline at the stage where the
  job is defined. To let the pipeline continue running, click **{play}** (play) on
  the blocking manual job.
2260

2261 2262 2263 2264 2265 2266 2267 2268 2269 2270
  Merge requests in projects with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
  enabled can't be merged with a blocked pipeline. Blocked pipelines show a status
  of **blocked**.

When you use [`rules:`](#rules), `allow_failure` defaults to `false`, including for manual jobs.

To trigger a manual job, a user must have permission to merge to the assigned branch.
You can use [protected branches](../../user/project/protected_branches.md) to more strictly
[protect manual deployments](#protecting-manual-jobs) from being run by unauthorized users.

2271 2272 2273
In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201938) and later, you
can use `when:manual` in the same job as [`trigger`](#trigger). In GitLab 13.4 and
earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
2274 2275 2276
It is deployed behind the `:ci_manual_bridges` [feature flag](../../user/feature_flags.md), which is **enabled by default**.
[GitLab administrators with access to the Rails console](../../administration/feature_flags.md)
can opt to disable it.
2277

2278
##### Protecting manual jobs **(PREMIUM)**
2279

2280 2281 2282
Use [protected environments](../environments/protected_environments.md)
to define a list of users authorized to run a manual job. You can authorize only
the users associated with a protected environment to trigger manual jobs, which can:
2283

2284 2285
- More precisely limit who can deploy to an environment.
- Block a pipeline until an approved user "approves" it.
2286

2287
To protect a manual job:
2288

2289
1. Add an `environment` to the job. For example:
2290

2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302
   ```yaml
   deploy_prod:
     stage: deploy
     script:
       - echo "Deploy to production server"
     environment:
       name: production
       url: https://example.com
     when: manual
     only:
       - master
   ```
2303

2304 2305 2306
1. In the [protected environments settings](../environments/protected_environments.md#protecting-environments),
   select the environment (`production` in the example above) and add the users, roles or groups
   that are authorized to trigger the manual job to the **Allowed to Deploy** list. Only those in
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2307
   this list can trigger this manual job, as well as GitLab administrators
2308
   who are always able to use protected environments.
2309

2310 2311 2312 2313
You can use protected environments with blocking manual jobs to have a list of users
allowed to approve later pipeline stages. Add `allow_failure: false` to the protected
manual job and the pipeline's next stages only run after the manual job is triggered
by authorized users.
2314

2315
#### `when:delayed`
2316

Marcel Amirault's avatar
Marcel Amirault committed
2317
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51352) in GitLab 11.4.
2318

2319 2320
Use `when: delayed` to execute scripts after a waiting period, or if you want to avoid
jobs immediately entering the `pending` state.
2321

2322 2323
You can set the period with `start_in` key. The value of `start_in` key is an elapsed time in seconds, unless a unit is
provided. `start_in` key must be less than or equal to one week. Examples of valid values include:
2324

2325
- `'5'`
2326
- `5 seconds`
2327 2328 2329
- `30 minutes`
- `1 day`
- `1 week`
2330

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2331
When there is a delayed job in a stage, the pipeline doesn't progress until the delayed job has finished.
2332
This keyword can also be used for inserting delays between different stages.
2333

2334
The timer of a delayed job starts immediately after the previous stage has completed.
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2335
Similar to other types of jobs, a delayed job's timer doesn't start unless the previous stage passed.
2336

2337
The following example creates a job named `timed rollout 10%` that is executed 30 minutes after the previous stage has completed:
2338

2339 2340 2341 2342 2343 2344 2345
```yaml
timed rollout 10%:
  stage: deploy
  script: echo 'Rolling out 10% ...'
  when: delayed
  start_in: 30 minutes
```
2346

Marcel Amirault's avatar
Marcel Amirault committed
2347
You can stop the active timer of a delayed job by clicking the **{time-out}** (**Unschedule**) button.
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2348
This job can no longer be scheduled to run automatically. You can, however, execute the job manually.
2349

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2350 2351
To start a delayed job immediately, click the **Play** button.
Soon GitLab Runner picks up and starts the job.
2352

2353
### `environment`
2354

2355
Use `environment` to define the [environment](../environments/index.md) that a job deploys to.
2356
If `environment` is specified and no environment under that name exists, a new
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2357
one is created automatically.
2358 2359

In its simplest form, the `environment` keyword can be defined like:
2360 2361

```yaml
2362 2363 2364 2365
deploy to production:
  stage: deploy
  script: git push production HEAD:master
  environment: production
2366 2367
```

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2368
In the above example, the `deploy to production` job is marked as doing a
2369
deployment to the `production` environment.
2370

2371
#### `environment:name`
2372

2373 2374 2375 2376
The `environment: name` keyword can use any of the defined CI variables,
including predefined, secure, or `.gitlab-ci.yml` [`variables`](#variables).

You can't use variables defined in a `script` section.
2377

2378
The `environment` name can contain:
2379

2380 2381 2382 2383 2384 2385 2386 2387 2388
- letters
- digits
- spaces
- `-`
- `_`
- `/`
- `$`
- `{`
- `}`
2389

2390 2391
Common names are `qa`, `staging`, and `production`, but you can use whatever
name works with your workflow.
2392

2393
Instead of defining the name of the environment right after the `environment`
Marcel Amirault's avatar
Marcel Amirault committed
2394
keyword, it's also possible to define it as a separate value. For that, use
2395
the `name` keyword under `environment`:
2396 2397

```yaml
2398 2399 2400 2401 2402
deploy to production:
  stage: deploy
  script: git push production HEAD:master
  environment:
    name: production
2403 2404
```

2405
#### `environment:url`
2406

2407 2408 2409 2410
The `url` keyword can use any of the defined CI variables,
including predefined, secure, or `.gitlab-ci.yml` [`variables`](#variables).

You can't use variables defined in a `script` section.
2411

2412
This optional value exposes buttons that take you to the defined URL
2413

2414 2415
In this example, if the job finishes successfully, it creates buttons
in the merge requests and in the environments/deployments pages that point
2416
to `https://prod.example.com`.
2417

2418 2419 2420 2421 2422 2423 2424 2425
```yaml
deploy to production:
  stage: deploy
  script: git push production HEAD:master
  environment:
    name: production
    url: https://prod.example.com
```
2426

2427
#### `environment:on_stop`
2428

Marcel Amirault's avatar
Marcel Amirault committed
2429
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/22191) in GitLab 8.13.
2430
> - Starting with GitLab 8.14, when you have an environment that has a stop action
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2431
>   defined, GitLab automatically triggers a stop action when the associated
2432
>   branch is deleted.
2433

2434 2435 2436
Closing (stopping) environments can be achieved with the `on_stop` keyword
defined under `environment`. It declares a different job that runs to close the
environment.
2437

2438
Read the `environment:action` section for an example.
2439

2440
#### `environment:action`
2441

Marcel Amirault's avatar
Marcel Amirault committed
2442
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/22191) in GitLab 8.13.
2443

2444 2445 2446 2447
The `action` keyword can be used to specify jobs that prepare, start, or stop environments.

| **Value** | **Description**                                                                                                                                               |
|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2448
| start     | Default value. Indicates that job starts the environment. The deployment is created after the job starts.                                                          |
2449 2450
| prepare   | Indicates that job is only preparing the environment. Does not affect deployments. [Read more about environments](../environments/index.md#prepare-an-environment) |
| stop      | Indicates that job stops deployment. See the example below.                                                                                                   |
2451

2452
Take for instance:
2453

2454 2455 2456 2457 2458
```yaml
review_app:
  stage: deploy
  script: make deploy-app
  environment:
2459 2460
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com
2461
    on_stop: stop_review_app
2462

2463 2464 2465 2466 2467 2468 2469
stop_review_app:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script: make delete-app
  when: manual
  environment:
2470
    name: review/$CI_COMMIT_REF_NAME
2471 2472
    action: stop
```
2473

2474 2475
In the above example, the `review_app` job deploys to the `review`
environment. A new `stop_review_app` job is listed under `on_stop`.
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2476
After the `review_app` job is finished, it triggers the
2477 2478
`stop_review_app` job based on what is defined under `when`. In this case,
it is set to `manual`, so it needs a [manual action](#whenmanual) from
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2479
GitLab's user interface to run.
2480

2481 2482 2483
Also in the example, `GIT_STRATEGY` is set to `none`. If the
`stop_review_app` job is [automatically triggered](../environments/index.md#automatically-stopping-an-environment),
the runner won’t try to check out the code after the branch is deleted.
2484

2485
The example also overwrites global variables. If your `stop` `environment` job depends
2486 2487
on global variables, use [anchor variables](#yaml-anchors-for-variables) when you set the `GIT_STRATEGY`
to change the job without overriding the global variables.
2488

2489
The `stop_review_app` job is **required** to have the following keywords defined:
2490

2491 2492 2493
- `when` - [reference](#when)
- `environment:name`
- `environment:action`
2494

2495
Additionally, both jobs should have matching [`rules`](../yaml/README.md#onlyexcept-basic)
2496
or [`only/except`](../yaml/README.md#onlyexcept-basic) configuration.
2497 2498 2499 2500 2501

In the example above, if the configuration is not identical:

- The `stop_review_app` job might not be included in all pipelines that include the `review_app` job.
- It is not possible to trigger the `action: stop` to stop the environment automatically.
2502

2503
#### `environment:auto_stop_in`
2504

2505
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/20956) in GitLab 12.8.
2506

2507
The `auto_stop_in` keyword is for specifying the lifetime of the environment,
2508
that when expired, GitLab automatically stops them.
2509

2510
For example,
2511

2512 2513 2514 2515 2516 2517 2518
```yaml
review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    auto_stop_in: 1 day
```
2519

2520 2521
When the environment for `review_app` is created, the environment's lifetime is set to `1 day`.
Every time the review app is deployed, that lifetime is also reset to `1 day`.
2522

2523
For more information, see
2524
[the environments auto-stop documentation](../environments/index.md#environments-auto-stop)
2525

2526
#### `environment:kubernetes`
2527

2528
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) in GitLab 12.6.
2529

2530 2531
The `kubernetes` block is used to configure deployments to a
[Kubernetes cluster](../../user/project/clusters/index.md) that is associated with your project.
2532

2533
For example:
2534

2535 2536 2537 2538 2539 2540 2541 2542 2543
```yaml
deploy:
  stage: deploy
  script: make deploy-app
  environment:
    name: production
    kubernetes:
      namespace: production
```
2544

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2545
This configuration sets up the `deploy` job to deploy to the `production`
2546 2547
environment, using the `production`
[Kubernetes namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).
2548

2549
For more information, see
2550
[Available settings for `kubernetes`](../environments/index.md#configuring-kubernetes-deployments).
2551

2552 2553 2554 2555
NOTE: **Note:**
Kubernetes configuration is not supported for Kubernetes clusters
that are [managed by GitLab](../../user/project/clusters/index.md#gitlab-managed-clusters).
To follow progress on support for GitLab-managed clusters, see the
2556
[relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/38054).
2557

2558
#### Dynamic environments
2559

Marcel Amirault's avatar
Marcel Amirault committed
2560 2561
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21971) in GitLab 8.12 and GitLab Runner 1.6.
> - The `$CI_ENVIRONMENT_SLUG` was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/22864) in GitLab 8.15.
2562 2563

Use CI/CD [variables](../variables/README.md) to dynamically name environments.
2564

2565
For example:
2566

2567 2568 2569 2570 2571 2572 2573 2574
```yaml
deploy as review app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com/
```
2575

2576 2577
The `deploy as review app` job is marked as a deployment to dynamically
create the `review/$CI_COMMIT_REF_NAME` environment. `$CI_COMMIT_REF_NAME`
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2578
is an [environment variable](../variables/README.md) set by the runner. The
2579
`$CI_ENVIRONMENT_SLUG` variable is based on the environment name, but suitable
2580 2581
for inclusion in URLs. If the `deploy as review app` job runs in a branch named
`pow`, this environment would be accessible with a URL like `https://review-pow.example.com/`.
2582

2583
The common use case is to create dynamic environments for branches and use them
2584
as Review Apps. You can see an example that uses Review Apps at
2585
<https://gitlab.com/gitlab-examples/review-apps-nginx/>.
2586

2587
### `cache`
2588

2589
`cache` is used to specify a list of files and directories that should be
2590
cached between jobs. You can only use paths that are in the local working copy.
2591

Marcel Amirault's avatar
Marcel Amirault committed
2592
If `cache` is defined outside the scope of jobs, it means it's set
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2593
globally and all jobs use that definition.
2594

2595 2596
Caching is shared between pipelines and jobs. Caches are restored before [artifacts](#artifacts).

2597 2598 2599
Read how caching works and find out some good practices in the
[caching dependencies documentation](../caching/index.md).

2600
#### `cache:paths`
2601

2602
Use the `paths` directive to choose which files or directories to cache. Paths
Marcel Amirault's avatar
Marcel Amirault committed
2603
are relative to the project directory (`$CI_PROJECT_DIR`) and can't directly link outside it.
2604
Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming))
2605 2606 2607 2608 2609 2610
patterns and:

- In [GitLab Runner 13.0](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2620) and later,
[`doublestar.Glob`](https://pkg.go.dev/github.com/bmatcuk/doublestar@v1.2.2?tab=doc#Match).
- In GitLab Runner 12.10 and earlier,
[`filepath.Match`](https://pkg.go.dev/path/filepath/#Match).
2611

2612
Cache all files in `binaries` that end in `.apk` and the `.config` file:
2613

2614 2615 2616 2617 2618 2619 2620 2621
```yaml
rspec:
  script: test
  cache:
    paths:
      - binaries/*.apk
      - .config
```
2622

2623
Locally defined cache overrides globally defined options. The following `rspec`
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2624
job caches only `binaries/`:
2625

2626
```yaml
2627 2628 2629
cache:
  paths:
    - my/files
2630

2631 2632 2633 2634
rspec:
  script: test
  cache:
    key: rspec
2635
    paths:
pityonline's avatar
pityonline committed
2636
      - binaries/
2637
```
2638

2639 2640 2641
The cache is shared between jobs, so if you're using different
paths for different jobs, you should also set a different `cache:key`.
Otherwise cache content can be overwritten.
2642

2643
#### `cache:key`
2644

2645
The `key` keyword defines the affinity of caching between jobs.
2646
You can have a single cache for all jobs, cache per-job, cache per-branch,
2647
or any other way that fits your workflow. You can fine tune caching,
2648
including caching data between different jobs or even different branches.
Shinya Maeda's avatar
Shinya Maeda committed
2649

2650
The `cache:key` variable can use any of the
2651 2652
[predefined variables](../variables/README.md). The default key, if not
set, is just literal `default`, which means everything is shared between
2653
pipelines and jobs by default.
Shinya Maeda's avatar
Shinya Maeda committed
2654

2655
For example, to enable per-branch caching:
2656

2657 2658 2659 2660 2661 2662
```yaml
cache:
  key: "$CI_COMMIT_REF_SLUG"
  paths:
    - binaries/
```
2663

2664 2665
If you use **Windows Batch** to run your shell scripts you need to replace
`$` with `%`:
2666 2667

```yaml
2668 2669 2670 2671 2672
cache:
  key: "%CI_COMMIT_REF_SLUG%"
  paths:
    - binaries/
```
2673

2674 2675 2676
The `cache:key` variable can't contain the `/` character, or the equivalent
URI-encoded `%2F`. A value made only of dots (`.`, `%2E`) is also forbidden.

2677 2678
You can specify a [fallback cache key](#fallback-cache-key) to use if the specified `cache:key` is not found.

2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704
#### Fallback cache key

> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1534) in GitLab Runner 13.4.

You can use the `$CI_COMMIT_REF_SLUG` [variable](#variables) to specify your [`cache:key`](#cachekey).
For example, if your `$CI_COMMIT_REF_SLUG` is `test` you can set a job
to download cache that's tagged with `test`.

If a cache with this tag is not found, you can use `CACHE_FALLBACK_KEY` to
specify a cache to use when none exists.

For example:

```yaml
variables:
  CACHE_FALLBACK_KEY: fallback-key

cache:
  key: "$CI_COMMIT_REF_SLUG"
  paths:
    - binaries/
```

In this example, if the `$CI_COMMIT_REF_SLUG` is not found, the job uses the key defined
by the `CACHE_FALLBACK_KEY` variable.

2705
##### `cache:key:files`
2706

2707
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18986) in GitLab v12.5.
2708

2709
The `cache:key:files` keyword extends the `cache:key` functionality by making it easier
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2710
to reuse some caches, and rebuild them less often, which speeds up subsequent pipeline
2711
runs.
2712

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2713 2714
When you include `cache:key:files`, you must also list the project files that are used to generate the key, up to a maximum of two files.
The cache `key` is a SHA checksum computed from the most recent commits (up to two, if two files are listed)
2715
that changed the given files. If neither file was changed in any commits,
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2716
the fallback key is `default`.
2717

2718 2719 2720 2721 2722 2723 2724 2725 2726 2727
```yaml
cache:
  key:
    files:
      - Gemfile.lock
      - package.json
  paths:
    - vendor/ruby
    - node_modules
```
2728

Marcel Amirault's avatar
Marcel Amirault committed
2729
In this example we're creating a cache for Ruby and Node.js dependencies that
2730 2731
is tied to current versions of the `Gemfile.lock` and `package.json` files. Whenever one of
these files changes, a new cache key is computed and a new cache is created. Any future
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2732
job runs that use the same `Gemfile.lock` and `package.json` with `cache:key:files`
2733
use the new cache, instead of rebuilding the dependencies.
2734

2735
##### `cache:key:prefix`
2736

2737
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18986) in GitLab v12.5.
2738

2739
When you want to combine a prefix with the SHA computed for `cache:key:files`,
2740
use the `prefix` keyword with `key:files`.
2741
For example, if you add a `prefix` of `test`, the resulting key is: `test-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`.
2742 2743
If neither file was changed in any commits, the prefix is added to `default`, so the
key in the example would be `test-default`.
2744

2745
Like `cache:key`, `prefix` can use any of the [predefined variables](../variables/README.md),
2746
but cannot include:
2747

2748 2749
- the `/` character (or the equivalent URI-encoded `%2F`)
- a value made only of `.` (or the equivalent URI-encoded `%2E`)
2750

2751 2752 2753 2754 2755 2756 2757 2758
```yaml
cache:
  key:
    files:
      - Gemfile.lock
    prefix: ${CI_JOB_NAME}
  paths:
    - vendor/ruby
2759

2760 2761 2762 2763
rspec:
  script:
    - bundle exec rspec
```
2764

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2765 2766
For example, adding a `prefix` of `$CI_JOB_NAME`
causes the key to look like: `rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5` and
2767
the job cache is shared across different branches. If a branch changes
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2768 2769
`Gemfile.lock`, that branch has a new SHA checksum for `cache:key:files`. A new cache key
is generated, and a new cache is created for that key.
2770 2771
If `Gemfile.lock` is not found, the prefix is added to
`default`, so the key in the example would be `rspec-default`.
2772

2773
#### `cache:untracked`
2774

2775 2776
Set `untracked: true` to cache all files that are untracked in your Git
repository:
2777

2778 2779 2780 2781 2782
```yaml
rspec:
  script: test
  cache:
    untracked: true
2783 2784
```

2785
Cache all Git untracked files and files in `binaries`:
2786

2787 2788 2789 2790 2791 2792 2793
```yaml
rspec:
  script: test
  cache:
    untracked: true
    paths:
      - binaries/
2794 2795
```

2796 2797 2798 2799 2800 2801 2802
#### `cache:when`

> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18969) in GitLab 13.5 and GitLab Runner v13.5.0.

`cache:when` defines when to save the cache, based on the status of the job. You can
set `cache:when` to:

2803 2804 2805
- `on_success` (default): Save the cache only when the job succeeds.
- `on_failure`: Save the cache only when the job fails.
- `always`: Always save the cache.
2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817

For example, to store a cache whether or not the job fails or succeeds:

```yaml
rspec:
  script: rspec
  cache:
    paths:
      - rspec/
    when: 'always'
```

2818
#### `cache:policy`
2819

2820
The default behavior of a caching job is to download the files at the start of
2821 2822
execution, and to re-upload them at the end. Any changes made by the
job are persisted for future runs. This behavior is known as the `pull-push` cache
2823
policy.
2824

Marcel Amirault's avatar
Marcel Amirault committed
2825
If you know the job does not alter the cached files, you can skip the upload step
2826 2827
by setting `policy: pull` in the job specification. You can add an ordinary cache
job at an earlier stage to ensure the cache is updated from time to time:
2828 2829

```yaml
2830 2831 2832 2833 2834 2835 2836 2837
stages:
  - setup
  - test

prepare:
  stage: setup
  cache:
    key: gems
2838
    paths:
2839 2840 2841
      - vendor/bundle
  script:
    - bundle install --deployment
2842 2843 2844

rspec:
  stage: test
2845 2846 2847 2848 2849 2850 2851
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - bundle exec rspec ...
2852 2853
```

2854 2855
The `pull` policy speeds up job execution and reduces load on the cache server. It
can be used when you have many jobs that use caches executing in parallel.
2856

2857 2858 2859
If you have a job that unconditionally recreates the cache without
referring to its previous contents, you can skip the download step.
To do so, add `policy: push` to the job.
2860

2861
### `artifacts`
2862

2863
`artifacts` is used to specify a list of files and directories that are
2864
attached to the job when it [succeeds, fails, or always](#artifactswhen).
2865

2866
The artifacts are sent to GitLab after the job finishes. They are
Suzanne Selhorn's avatar
Suzanne Selhorn committed
2867
available for download in the GitLab UI if the size is not
2868
larger than the [maximum artifact size](../../user/gitlab_com/index.md#gitlab-cicd).
2869

2870 2871 2872 2873 2874
Job artifacts are only collected for successful jobs by default, and
artifacts are restored after [caches](#cache).

[Not all executors can use caches](https://docs.gitlab.com/runner/executors/#compatibility-chart).

2875
[Read more about artifacts](../pipelines/job_artifacts.md).
2876

2877
#### `artifacts:paths`
2878

Marcel Amirault's avatar
Marcel Amirault committed
2879
Paths are relative to the project directory (`$CI_PROJECT_DIR`) and can't directly
2880
link outside it. Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming))
2881 2882 2883 2884 2885 2886
patterns and:

- In [GitLab Runner 13.0](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2620) and later,
[`doublestar.Glob`](https://pkg.go.dev/github.com/bmatcuk/doublestar@v1.2.2?tab=doc#Match).
- In GitLab Runner 12.10 and earlier,
[`filepath.Match`](https://pkg.go.dev/path/filepath/#Match).
2887

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2888
To restrict which jobs a specific job fetches artifacts from, see [dependencies](#dependencies).
2889 2890

Send all files in `binaries` and `.config`:
2891 2892

```yaml
2893 2894 2895 2896
artifacts:
  paths:
    - binaries/
    - .config
2897 2898
```

2899
To disable artifact passing, define the job with empty [dependencies](#dependencies):
2900

2901 2902 2903 2904 2905 2906
```yaml
job:
  stage: build
  script: make build
  dependencies: []
```
2907

2908 2909
You may want to create artifacts only for tagged releases to avoid filling the
build server storage with temporary build artifacts.
2910

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2911
Create artifacts only for tags (`default-job` doesn't create artifacts):
2912

2913 2914 2915 2916 2917 2918
```yaml
default-job:
  script:
    - mvn test -U
  except:
    - tags
2919

2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930
release-job:
  script:
    - mvn package -U
  artifacts:
    paths:
      - target/*.war
  only:
    - tags
```

You can use wildcards for directories too. For example, if you want to get all the files inside the directories that end with `xyz`:
2931 2932

```yaml
2933 2934 2935 2936
job:
  artifacts:
    paths:
      - path/*xyz/*
2937 2938
```

2939 2940
#### `artifacts:exclude`

Amy Qualls's avatar
Amy Qualls committed
2941
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15122) in GitLab 13.1
2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965
> - Requires GitLab Runner 13.1

`exclude` makes it possible to prevent files from being added to an artifacts
archive.

Similar to [`artifacts:paths`](#artifactspaths), `exclude` paths are relative
to the project directory. Wildcards can be used that follow the
[glob](https://en.wikipedia.org/wiki/Glob_(programming)) patterns and
[`filepath.Match`](https://golang.org/pkg/path/filepath/#Match).

For example, to store all files in `binaries/`, but not `*.o` files located in
subdirectories of `binaries/`:

```yaml
artifacts:
  paths:
    - binaries/
  exclude:
    - binaries/**/*.o
```

Files matched by [`artifacts:untracked`](#artifactsuntracked) can be excluded using
`artifacts:exclude` too.

2966
#### `artifacts:expose_as`
2967

2968
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15018) in GitLab 12.5.
2969

2970 2971
The `expose_as` keyword can be used to expose [job artifacts](../pipelines/job_artifacts.md)
in the [merge request](../../user/project/merge_requests/index.md) UI.
2972

2973
For example, to match a single file:
2974

2975
```yaml
2976
test:
Marcel Amirault's avatar
Marcel Amirault committed
2977
  script: ["echo 'test' > file.txt"]
2978 2979
  artifacts:
    expose_as: 'artifact 1'
2980
    paths: ['file.txt']
2981
```
2982

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2983
With this configuration, GitLab adds a link **artifact 1** to the relevant merge request
2984
that points to `file1.txt`.
2985

Suzanne Selhorn's avatar
Suzanne Selhorn committed
2986
An example that matches an entire directory:
2987

2988
```yaml
2989
test:
Marcel Amirault's avatar
Marcel Amirault committed
2990
  script: ["mkdir test && echo 'test' > test/file.txt"]
2991 2992
  artifacts:
    expose_as: 'artifact 1'
2993
    paths: ['test/']
2994 2995
```

2996 2997
Note the following:

2998
- Artifacts do not display in the merge request UI when using variables to define the `artifacts:paths`.
2999 3000
- A maximum of 10 job artifacts per merge request can be exposed.
- Glob patterns are unsupported.
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3001
- If a directory is specified, the link is to the job [artifacts browser](../pipelines/job_artifacts.md#browsing-artifacts) if there is more than
3002 3003 3004
  one file in the directory.
- For exposed single file artifacts with `.html`, `.htm`, `.txt`, `.json`, `.xml`,
  and `.log` extensions, if [GitLab Pages](../../administration/pages/index.md) is:
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3005 3006
  - Enabled, GitLab automatically renders the artifact.
  - Not enabled, the file is displayed in the artifacts browser.
3007 3008 3009

#### `artifacts:name`

3010
Use the `name` directive to define the name of the created artifacts
3011
archive. You can specify a unique name for every archive. The `artifacts:name`
3012
variable can make use of any of the [predefined variables](../variables/README.md).
3013
The default name is `artifacts`, which becomes `artifacts.zip` when you download it.
3014 3015

To create an archive with a name of the current job:
Markus Doits's avatar
Markus Doits committed
3016

3017 3018 3019 3020 3021 3022 3023
```yaml
job:
  artifacts:
    name: "$CI_JOB_NAME"
    paths:
      - binaries/
```
3024

3025 3026
To create an archive with a name of the current branch or tag including only
the binaries directory:
3027 3028

```yaml
3029 3030 3031 3032 3033
job:
  artifacts:
    name: "$CI_COMMIT_REF_NAME"
    paths:
      - binaries/
3034 3035
```

3036 3037 3038 3039
If your branch-name contains forward slashes
(for example `feature/my-feature`) it's advised to use `$CI_COMMIT_REF_SLUG`
instead of `$CI_COMMIT_REF_NAME` for proper naming of the artifact.

3040 3041
To create an archive with a name of the current job and the current branch or
tag including only the binaries directory:
3042 3043

```yaml
3044 3045 3046 3047 3048
job:
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    paths:
      - binaries/
3049 3050
```

3051
To create an archive with a name of the current [stage](#stages) and branch name:
3052

3053 3054 3055 3056 3057 3058 3059
```yaml
job:
  artifacts:
    name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"
    paths:
      - binaries/
```
3060

3061
---
3062

3063 3064
If you use **Windows Batch** to run your shell scripts you need to replace
`$` with `%`:
3065

3066 3067 3068 3069 3070 3071 3072
```yaml
job:
  artifacts:
    name: "%CI_JOB_STAGE%-%CI_COMMIT_REF_NAME%"
    paths:
      - binaries/
```
3073

3074 3075
If you use **Windows PowerShell** to run your shell scripts you need to replace
`$` with `$env:`:
3076 3077

```yaml
3078 3079 3080 3081 3082
job:
  artifacts:
    name: "$env:CI_JOB_STAGE-$env:CI_COMMIT_REF_NAME"
    paths:
      - binaries/
3083 3084
```

3085
#### `artifacts:untracked`
Matija Čupić's avatar
Matija Čupić committed
3086

3087
`artifacts:untracked` is used to add all Git untracked files as artifacts (along
3088 3089
to the paths defined in `artifacts:paths`). `artifacts:untracked` ignores configuration
in the repository's `.gitignore` file.
Matija Čupić's avatar
Matija Čupić committed
3090

3091
Send all Git untracked files:
Matija Čupić's avatar
Matija Čupić committed
3092

3093 3094 3095 3096
```yaml
artifacts:
  untracked: true
```
Matija Čupić's avatar
Matija Čupić committed
3097

3098
Send all Git untracked files and files in `binaries`:
Matija Čupić's avatar
Matija Čupić committed
3099

3100
```yaml
3101 3102 3103 3104
artifacts:
  untracked: true
  paths:
    - binaries/
Matija Čupić's avatar
Matija Čupić committed
3105
```
3106

3107 3108 3109 3110 3111 3112
Send all untracked files but [exclude](#artifactsexclude) `*.txt`:

```yaml
artifacts:
  untracked: true
  exclude:
3113
    - "*.txt"
3114 3115
```

3116
#### `artifacts:when`
3117

3118 3119
`artifacts:when` is used to upload artifacts on job failure or despite the
failure.
3120

3121
`artifacts:when` can be set to one of the following values:
3122

3123 3124 3125
1. `on_success` (default): Upload artifacts only when the job succeeds.
1. `on_failure`: Upload artifacts only when the job fails.
1. `always`: Always upload artifacts.
3126

3127
For example, to upload artifacts only when a job fails:
3128

3129 3130 3131 3132 3133
```yaml
job:
  artifacts:
    when: on_failure
```
3134

3135
#### `artifacts:expire_in`
Evan Read's avatar
Evan Read committed
3136

3137 3138 3139 3140
Use `expire_in` to specify how long artifacts are active before they
expire and are deleted.

The expiration time period begins when the artifact is uploaded and
3141
stored on GitLab. If the expiry time is not defined, it defaults to the
3142
[instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration)
3143
(30 days by default).
Evan Read's avatar
Evan Read committed
3144

3145
To override the expiration date and protect artifacts from being automatically deleted:
3146 3147 3148 3149

- Use the **Keep** button on the job page.
- Set the value of `expire_in` to `never`. [Available](https://gitlab.com/gitlab-org/gitlab/-/issues/22761)
  in GitLab 13.3 and later.
3150

3151 3152
After their expiry, artifacts are deleted hourly by default (via a cron job),
and are not accessible anymore.
Evan Read's avatar
Evan Read committed
3153

3154
The value of `expire_in` is an elapsed time in seconds, unless a unit is
Marcel Amirault's avatar
Marcel Amirault committed
3155
provided. Examples of valid values:
3156

3157 3158
- `'42'`
- `42 seconds`
Marcel Amirault's avatar
Marcel Amirault committed
3159 3160 3161 3162 3163 3164
- `3 mins 4 sec`
- `2 hrs 20 min`
- `2h20min`
- `6 mos 1 day`
- `47 yrs 6 mos and 4d`
- `3 weeks and 2 days`
3165
- `never`
Evan Read's avatar
Evan Read committed
3166

3167
To expire artifacts 1 week after being uploaded:
Evan Read's avatar
Evan Read committed
3168 3169

```yaml
3170 3171 3172
job:
  artifacts:
    expire_in: 1 week
Evan Read's avatar
Evan Read committed
3173 3174
```

3175 3176 3177 3178
The latest artifacts for refs are locked against deletion, and kept regardless of
the expiry time. [Introduced in](https://gitlab.com/gitlab-org/gitlab/-/issues/16267)
GitLab 13.0 behind a disabled feature flag, and [made the default behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/229936)
in GitLab 13.4.
3179

3180
#### `artifacts:reports`
Evan Read's avatar
Evan Read committed
3181

3182 3183
The [`artifacts:reports` keyword](../pipelines/job_artifacts.md#artifactsreports)
is used for collecting test reports, code quality reports, and security reports from jobs.
3184
It also exposes these reports in GitLab's UI (merge requests, pipeline views, and security dashboards).
3185

3186 3187
These are the available report types:

3188 3189 3190 3191
| Keyword                                                                                                                     | Description                                                                      |
|-----------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|
| [`artifacts:reports:cobertura`](../pipelines/job_artifacts.md#artifactsreportscobertura)                                    | The `cobertura` report collects Cobertura coverage XML files.                    |
| [`artifacts:reports:codequality`](../pipelines/job_artifacts.md#artifactsreportscodequality)                                | The `codequality` report collects CodeQuality issues.                            |
3192 3193 3194
| [`artifacts:reports:container_scanning`](../pipelines/job_artifacts.md#artifactsreportscontainer_scanning) **(ULTIMATE)**   | The `container_scanning` report collects Container Scanning vulnerabilities.     |
| [`artifacts:reports:dast`](../pipelines/job_artifacts.md#artifactsreportsdast) **(ULTIMATE)**                               | The `dast` report collects Dynamic Application Security Testing vulnerabilities. |
| [`artifacts:reports:dependency_scanning`](../pipelines/job_artifacts.md#artifactsreportsdependency_scanning) **(ULTIMATE)** | The `dependency_scanning` report collects Dependency Scanning vulnerabilities.   |
3195 3196
| [`artifacts:reports:dotenv`](../pipelines/job_artifacts.md#artifactsreportsdotenv)                                          | The `dotenv` report collects a set of environment variables.                     |
| [`artifacts:reports:junit`](../pipelines/job_artifacts.md#artifactsreportsjunit)                                            | The `junit` report collects JUnit XML files.                                     |
3197 3198
| [`artifacts:reports:license_management`](../pipelines/job_artifacts.md#artifactsreportslicense_management) **(ULTIMATE)**   | The `license_management` report collects Licenses (*removed from GitLab 13.0*).  |
| [`artifacts:reports:license_scanning`](../pipelines/job_artifacts.md#artifactsreportslicense_scanning) **(ULTIMATE)**       | The `license_scanning` report collects Licenses.                                 |
3199 3200 3201
| [`artifacts:reports:load_performance`](../pipelines/job_artifacts.md#artifactsreportsload_performance) **(PREMIUM)**        | The `load_performance` report collects load performance metrics.                 |
| [`artifacts:reports:metrics`](../pipelines/job_artifacts.md#artifactsreportsmetrics) **(PREMIUM)**                          | The `metrics` report collects Metrics.                                           |
| [`artifacts:reports:performance`](../pipelines/job_artifacts.md#artifactsreportsperformance) **(PREMIUM)**                  | The `performance` report collects Browser Performance metrics.                   |
3202
| [`artifacts:reports:sast`](../pipelines/job_artifacts.md#artifactsreportssast) **(ULTIMATE)**                               | The `sast` report collects Static Application Security Testing vulnerabilities.  |
3203
| [`artifacts:reports:terraform`](../pipelines/job_artifacts.md#artifactsreportsterraform)                                    | The `terraform` report collects Terraform `tfplan.json` files.                   |
Evan Read's avatar
Evan Read committed
3204

3205
#### `dependencies`
3206

3207
By default, all [`artifacts`](#artifacts) from previous [stages](#stages)
3208
are passed to each job. However, you can use the `dependencies` keyword to
3209
define a limited list of jobs to fetch artifacts from. You can also set a job to download no artifacts at all.
3210

3211
To use this feature, define `dependencies` in context of the job and pass
3212
a list of all previous jobs the artifacts should be downloaded from.
3213

3214 3215 3216 3217 3218 3219 3220 3221 3222
You can define jobs from stages that were executed before the current one.
An error occurs if you define jobs from the current or an upcoming stage.

To prevent a job from downloading artifacts, define an empty array.

When you use `dependencies`, the status of the previous job is not considered.
If a job fails or it's a manual job that was not run, no error occurs.

The following example defines two jobs with artifacts: `build:osx` and
3223
`build:linux`. When the `test:osx` is executed, the artifacts from `build:osx`
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3224
are downloaded and extracted in the context of the build. The same happens
3225
for `test:linux` and artifacts from `build:linux`.
3226

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3227
The job `deploy` downloads artifacts from all previous jobs because of
3228
the [stage](#stages) precedence:
3229

3230
```yaml
3231 3232 3233 3234 3235 3236
build:osx:
  stage: build
  script: make build:osx
  artifacts:
    paths:
      - binaries/
3237

3238 3239 3240 3241 3242 3243
build:linux:
  stage: build
  script: make build:linux
  artifacts:
    paths:
      - binaries/
3244

3245 3246 3247 3248 3249
test:osx:
  stage: test
  script: make test:osx
  dependencies:
    - build:osx
3250

3251 3252 3253 3254 3255
test:linux:
  stage: test
  script: make test:linux
  dependencies:
    - build:linux
3256

3257 3258 3259
deploy:
  stage: deploy
  script: make deploy
3260 3261
```

3262
##### When a dependent job fails
3263

3264
> Introduced in GitLab 10.3.
3265

3266 3267 3268
If the artifacts of the job that is set as a dependency have been
[expired](#artifactsexpire_in) or
[erased](../pipelines/job_artifacts.md#erasing-artifacts), then
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3269
the dependent job fails.
3270

3271 3272 3273
You can ask your administrator to
[flip this switch](../../administration/job_artifacts.md#validation-for-dependencies)
and bring back the old behavior.
3274

3275
### `coverage`
3276

Marcel Amirault's avatar
Marcel Amirault committed
3277
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/20428) in GitLab 8.17.
3278

3279
Use `coverage` to configure how code coverage is extracted from the
3280
job output.
3281

3282
Regular expressions are the only valid kind of value expected here. So, using
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3283
surrounding `/` is mandatory to consistently and explicitly represent
3284 3285
a regular expression string. You must escape special characters if you want to
match them literally.
3286

3287
For example:
3288

3289
```yaml
3290 3291 3292
job1:
  script: rspec
  coverage: '/Code coverage: \d+\.\d+/'
3293 3294
```

3295
### `retry`
3296

Marcel Amirault's avatar
Marcel Amirault committed
3297
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/3442) in GitLab 9.5.
3298
> - [Behavior expanded](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3515) in GitLab 11.5 to control which failures to retry on.
3299

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3300
Use `retry` to configure how many times a job is retried in
3301
case of a failure.
3302

3303 3304
When a job fails, the job is processed again,
until the limit specified by the `retry` keyword is reached.
3305

3306 3307 3308
If `retry` is set to `2`, and a job succeeds in a second run (first retry), it is not retried.
The `retry` value must be a positive integer, from `0` to `2`
(two retries maximum, three runs in total).
3309

3310
This example retries all failure cases:
3311

3312
```yaml
3313 3314 3315
test:
  script: rspec
  retry: 2
3316
```
3317

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3318
By default, a job is retried on all failure cases. To have better control
3319
over which failures to retry, `retry` can be a hash with the following keys:
3320

3321 3322
- `max`: The maximum number of retries.
- `when`: The failure cases to retry.
3323

3324
To retry only runner system failures at maximum two times:
3325

3326 3327 3328 3329 3330 3331 3332
```yaml
test:
  script: rspec
  retry:
    max: 2
    when: runner_system_failure
```
3333

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3334 3335
If there is another failure, other than a runner system failure, the job
is not retried.
3336

3337
To retry on multiple failure cases, `when` can also be an array of failures:
3338

3339 3340 3341 3342 3343 3344 3345 3346 3347
```yaml
test:
  script: rspec
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure
```
3348

3349
Possible values for `when` are:
3350

3351
<!--
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3352 3353 3354 3355
  If you change any of the values below, make sure to update the `RETRY_WHEN_IN_DOCUMENTATION`
  array in `spec/lib/gitlab/ci/config/entry/retry_spec.rb`.
  The test there makes sure that all documented
  values are valid as a configuration option and therefore should always
3356
  stay in sync with this documentation.
3357
-->
3358

3359 3360 3361 3362 3363
- `always`: Retry on any failure (default).
- `unknown_failure`: Retry when the failure reason is unknown.
- `script_failure`: Retry when the script failed.
- `api_failure`: Retry on API failure.
- `stuck_or_timeout_failure`: Retry when the job got stuck or timed out.
Marcel Amirault's avatar
Marcel Amirault committed
3364
- `runner_system_failure`: Retry if there was a runner system failure (for example, job setup failed).
3365 3366 3367 3368
- `missing_dependency_failure`: Retry if a dependency was missing.
- `runner_unsupported`: Retry if the runner was unsupported.
- `stale_schedule`: Retry if a delayed job could not be executed.
- `job_execution_timeout`: Retry if the script exceeded the maximum execution time set for the job.
Marcel Amirault's avatar
Marcel Amirault committed
3369
- `archived_failure`: Retry if the job is archived and can't be run.
3370 3371 3372
- `unmet_prerequisites`: Retry if the job failed to complete prerequisite tasks.
- `scheduler_failure`: Retry if the scheduler failed to assign the job to a runner.
- `data_integrity_failure`: Retry if there was a structural integrity problem detected.
3373

3374
You can specify the number of [retry attempts for certain stages of job execution](../runners/README.md#job-stages-attempts) using variables.
3375

3376
### `timeout`
3377

3378
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14887) in GitLab 12.3.
3379

3380
Use `timeout` to configure a timeout for a specific job. For example:
3381

3382
```yaml
3383 3384 3385 3386 3387 3388 3389
build:
  script: build.sh
  timeout: 3 hours 30 minutes

test:
  script: rspec
  timeout: 3h 30m
3390 3391
```

3392
The job-level timeout can exceed the
Marcel Amirault's avatar
Marcel Amirault committed
3393
[project-level timeout](../pipelines/settings.md#timeout) but can't
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3394
exceed the runner-specific timeout.
3395

3396
### `parallel`
3397

Marcel Amirault's avatar
Marcel Amirault committed
3398
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21480) in GitLab 11.5.
3399

3400 3401
Use `parallel` to configure how many instances of a job to run in parallel.
The value can be from 2 to 50.
3402

3403 3404
The `parallel` keyword creates N instances of the same job that run in parallel.
They are named sequentially from `job_name 1/N` to `job_name N/N`:
3405

3406
```yaml
3407 3408 3409
test:
  script: rspec
  parallel: 5
3410
```
3411

3412 3413
Every parallel job has a `CI_NODE_INDEX` and `CI_NODE_TOTAL`
[environment variable](../variables/README.md#predefined-environment-variables) set.
3414

3415 3416 3417
Different languages and test suites have different methods to enable parallelization.
For example, use [Semaphore Test Boosters](https://github.com/renderedtext/test-boosters)
and RSpec to run Ruby tests in parallel:
3418

3419 3420 3421
```ruby
# Gemfile
source 'https://rubygems.org'
3422

3423 3424 3425
gem 'rspec'
gem 'semaphore_test_boosters'
```
3426

3427
```yaml
3428 3429
test:
  parallel: 3
3430
  script:
3431 3432
    - bundle
    - bundle exec rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL
3433
```
3434

3435
CAUTION: **Caution:**
3436
Test Boosters reports usage statistics to the author.
3437

3438 3439
You can then navigate to the **Jobs** tab of a new pipeline build and see your RSpec
job split into three separate jobs.
3440

3441 3442
#### Parallel `matrix` jobs

3443
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15356) in GitLab 13.3.
3444

3445
Use `matrix:` to configure different variables for jobs that are running in parallel.
3446 3447
There can be from 2 to 50 jobs.

3448 3449
[In GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/26362) and later,
you can have one-dimensional matrices with a single job.
3450

3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470
Every job gets the same `CI_NODE_TOTAL` [environment variable](../variables/README.md#predefined-environment-variables) value, and a unique `CI_NODE_INDEX` value.

```yaml
deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2
      - PROVIDER: ovh
        STACK: [monitoring, backup, app]
      - PROVIDER: [gcp, vultr]
        STACK: [data, processing]
```

3471 3472
This example generates 10 parallel `deploystacks` jobs, each with different values
for `PROVIDER` and `STACK`:
3473 3474

```plaintext
3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486
deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [aws, app2]
deploystacks: [ovh, monitoring]
deploystacks: [ovh, backup]
deploystacks: [ovh, app]
deploystacks: [gcp, data]
deploystacks: [gcp, processing]
deploystacks: [vultr, data]
deploystacks: [vultr, processing]
```

3487
The job naming style was [improved in GitLab 13.4](https://gitlab.com/gitlab-org/gitlab/-/issues/230452).
3488

3489
### `trigger`
3490

3491 3492
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8997) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Core in 12.8.
3493

3494 3495
Use `trigger` to define a downstream pipeline trigger. When GitLab starts a job created
with a `trigger` definition, a downstream pipeline is created.
3496

3497
Jobs with `trigger` can only use a [limited set of keywords](../multi_project_pipelines.md#limitations).
3498 3499
For example, you can't run commands with [`script`](#script), [`before_script`](#before_script),
or [`after_script`](#after_script).
3500

3501
You can use this keyword to create two different types of downstream pipelines:
3502

3503 3504
- [Multi-project pipelines](../multi_project_pipelines.md#creating-multi-project-pipelines-from-gitlab-ciyml)
- [Child pipelines](../parent_child_pipelines.md)
3505

3506
[In GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/) and later, you can
3507 3508
view which job triggered a downstream pipeline. In the [pipeline graph](../pipelines/index.md#visualize-pipelines),
hover over the downstream pipeline job.
3509

3510 3511 3512
In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201938) and later, you
can use [`when:manual`](#whenmanual) in the same job as `trigger`. In GitLab 13.4 and
earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
3513 3514 3515
It is deployed behind the `:ci_manual_bridges` [feature flag](../../user/feature_flags.md), which is **enabled by default**.
[GitLab administrators with access to the Rails console](../../administration/feature_flags.md)
can opt to disable it.
3516

3517
#### Simple `trigger` syntax for multi-project pipelines
3518

3519 3520
The simplest way to configure a downstream trigger is to use `trigger` keyword
with a full path to a downstream project:
3521

3522 3523 3524 3525
```yaml
rspec:
  stage: test
  script: bundle exec rspec
3526

3527 3528 3529 3530
staging:
  stage: deploy
  trigger: my/deployment
```
3531

3532
#### Complex `trigger` syntax for multi-project pipelines
3533

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3534
You can configure a branch name that GitLab uses to create
3535
a downstream pipeline with:
3536

3537
```yaml
3538 3539 3540 3541 3542 3543 3544 3545 3546
rspec:
  stage: test
  script: bundle exec rspec

staging:
  stage: deploy
  trigger:
    project: my/deployment
    branch: stable
3547 3548
```

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3549
To mirror the status from a triggered pipeline:
3550

3551
```yaml
3552 3553 3554 3555 3556
trigger_job:
  trigger:
    project: my/project
    strategy: depend
```
3557

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3558
To mirror the status from an upstream pipeline:
3559

3560 3561 3562 3563 3564
```yaml
upstream_bridge:
  stage: test
  needs:
    pipeline: other/project
3565 3566
```

3567
#### `trigger` syntax for child pipeline
3568

3569
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) in GitLab 12.7.
3570

3571 3572
To create a [child pipeline](../parent_child_pipelines.md), specify the path to the
YAML file containing the CI config of the child pipeline:
3573 3574

```yaml
3575 3576 3577
trigger_job:
  trigger:
    include: path/to/child-pipeline.yml
3578 3579
```

3580
Similar to [multi-project pipelines](../multi_project_pipelines.md#mirroring-status-from-triggered-pipeline),
Marcel Amirault's avatar
Marcel Amirault committed
3581
it's possible to mirror the status from a triggered pipeline:
3582 3583

```yaml
3584 3585 3586 3587 3588
trigger_job:
  trigger:
    include:
      - local: path/to/child-pipeline.yml
    strategy: depend
3589 3590
```

3591
##### Trigger child pipeline with generated configuration file
3592

3593
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) in GitLab 12.9.
3594

3595
You can also trigger a child pipeline from a [dynamically generated configuration file](../parent_child_pipelines.md#dynamic-child-pipelines):
3596 3597

```yaml
3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610
generate-config:
  stage: build
  script: generate-ci-config > generated-config.yml
  artifacts:
    paths:
      - generated-config.yml

child-pipeline:
  stage: test
  trigger:
    include:
      - artifact: generated-config.yml
        job: generate-config
3611 3612
```

3613 3614 3615
The `generated-config.yml` is extracted from the artifacts and used as the configuration
for triggering the child pipeline.

3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631
##### Trigger child pipeline with files from another project

> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) in GitLab 13.5.

To trigger child pipelines with files from another private project under the same
GitLab instance, use [`include:file`](#includefile):

```yaml
child-pipeline:
  trigger:
    include:
      - project: 'my-group/my-pipeline-library'
        ref: 'master'
        file: '/path/to/child-pipeline.yml'
```

3632 3633 3634 3635 3636 3637
#### Linking pipelines with `trigger:strategy`

By default, the `trigger` job completes with the `success` status
as soon as the downstream pipeline is created.

To force the `trigger` job to wait for the downstream (multi-project or child) pipeline to complete, use
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3638 3639
`strategy: depend`. This setting makes the trigger job wait with a "running" status until the triggered
pipeline completes. At that point, the `trigger` job completes and displays the same status as
3640
the downstream job.
3641 3642

```yaml
3643 3644 3645 3646
trigger_job:
  trigger:
    include: path/to/child-pipeline.yml
    strategy: depend
3647 3648
```

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3649 3650
This setting can help keep your pipeline execution linear. In the example above, jobs from
subsequent stages wait for the triggered pipeline to successfully complete before
3651
starting, which reduces parallelization.
3652

3653
#### Trigger a pipeline by API call
3654

3655 3656
To force a rebuild of a specific branch, tag, or commit, you can use an API call
with a trigger token.
3657

3658
The trigger token is different than the [`trigger`](#trigger) keyword.
3659

3660
[Read more in the triggers documentation.](../triggers/README.md)
3661

3662
### `interruptible`
3663

Marcel Amirault's avatar
Marcel Amirault committed
3664
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32022) in GitLab 12.3.
3665

3666
`interruptible` is used to indicate that a job should be canceled if made redundant by a newer pipeline run. Defaults to `false`.
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3667
This value is used only if the [automatic cancellation of redundant pipelines feature](../pipelines/settings.md#auto-cancel-pending-pipelines)
3668
is enabled.
3669

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3670
When enabled, a pipeline on the same branch is canceled when:
3671

3672
- It's made redundant by a newer pipeline run.
Marcel Amirault's avatar
Marcel Amirault committed
3673
- Either all jobs are set as interruptible, or any uninterruptible jobs haven't started.
3674

3675
Set jobs as interruptible that can be safely canceled once started (for instance, a build job).
3676

3677 3678
Pending jobs are always considered interruptible.

3679
For example:
3680 3681

```yaml
3682 3683 3684 3685
stages:
  - stage1
  - stage2
  - stage3
3686

3687 3688 3689 3690 3691
step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true
3692

3693 3694 3695 3696
step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."
3697

3698 3699 3700
step-3:
  stage: stage3
  script:
3701
    - echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
3702
  interruptible: true
3703 3704
```

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3705
In the example above, a new pipeline run causes an existing running pipeline to be:
Wolphin's avatar
Wolphin committed
3706

3707 3708
- Canceled, if only `step-1` is running or pending.
- Not canceled, once `step-2` starts running.
Wolphin's avatar
Wolphin committed
3709

Suzanne Selhorn's avatar
Suzanne Selhorn committed
3710
When an uninterruptible job is running, the pipeline can never be canceled, regardless of the final job's state.
Wolphin's avatar
Wolphin committed
3711

3712
### `resource_group`
Wolphin's avatar
Wolphin committed
3713

3714
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15536) in GitLab 12.7.
Wolphin's avatar
Wolphin committed
3715

3716
Sometimes running multiple jobs or pipelines at the same time in an environment
3717
can lead to errors during the deployment.
Wolphin's avatar
Wolphin committed
3718

3719
To avoid these errors, the `resource_group` attribute can be used to ensure that
3720
the runner doesn't run certain jobs simultaneously. Resource groups behave similar
3721
to semaphores in other programming languages.
3722

3723 3724 3725
When the `resource_group` key is defined for a job in `.gitlab-ci.yml`,
job executions are mutually exclusive across different pipelines for the same project.
If multiple jobs belonging to the same resource group are enqueued simultaneously,
3726
only one of the jobs is picked by the runner. The other jobs wait until the
3727
`resource_group` is free.
3728

3729
For example:
3730 3731

```yaml
3732 3733 3734
deploy-to-production:
  script: deploy
  resource_group: production
3735 3736
```

3737
In this case, two `deploy-to-production` jobs in two separate pipelines can never run at the same time. As a result,
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3738
you can ensure that concurrent deployments never happen to the production environment.
3739

3740 3741
You can define multiple resource groups per environment. For example,
when deploying to physical devices, you may have multiple physical devices. Each device
3742
can be deployed to, but there can be only one deployment per device at any given time.
3743

3744
The `resource_group` value can only contain letters, digits, `-`, `_`, `/`, `$`, `{`, `}`, `.`, and spaces.
Marcel Amirault's avatar
Marcel Amirault committed
3745
It can't start or end with `/`.
3746

Shinya Maeda's avatar
Shinya Maeda committed
3747 3748
For more information, see [Deployments Safety](../environments/deployment_safety.md).

3749 3750 3751 3752
### `release`

> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/19298) in GitLab 13.2.

3753
`release` indicates that the job creates a [Release](../../user/project/releases/index.md).
3754 3755 3756 3757

These methods are supported:

- [`tag_name`](#releasetag_name)
3758
- [`description`](#releasedescription)
3759 3760 3761 3762
- [`name`](#releasename) (optional)
- [`ref`](#releaseref) (optional)
- [`milestones`](#releasemilestones) (optional)
- [`released_at`](#releasereleased_at) (optional)
3763 3764 3765 3766 3767 3768 3769 3770 3771

The Release is created only if the job processes without error. If the Rails API
returns an error during Release creation, the `release` job fails.

#### `release-cli` Docker image

The Docker image to use for the `release-cli` must be specified, using the following directive:

```yaml
3772
image: registry.gitlab.com/gitlab-org/release-cli:latest
3773 3774 3775 3776
```

#### Script

3777 3778 3779
All jobs except [trigger](#trigger) jobs must have the `script` keyword. A `release`
job can use the output from script commands, but a placeholder script can be used if
the script is not needed:
3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791

```yaml
script:
  - echo 'release job'
```

An [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/223856) exists to remove this requirement in an upcoming version of GitLab.

A pipeline can have multiple `release` jobs, for example:

```yaml
ios-release:
3792 3793
  script:
    - echo 'iOS release job'
3794
  release:
Marcel Amirault's avatar
Marcel Amirault committed
3795 3796
    tag_name: v1.0.0-ios
    description: 'iOS release v1.0.0'
3797 3798

android-release:
3799 3800
  script:
    - echo 'Android release job'
3801
  release:
Marcel Amirault's avatar
Marcel Amirault committed
3802 3803
    tag_name: v1.0.0-android
    description: 'Android release v1.0.0'
3804 3805 3806 3807 3808 3809
```

#### `release:tag_name`

The `tag_name` must be specified. It can refer to an existing Git tag or can be specified by the user.

3810
When the specified tag doesn't exist in the repository, a new tag is created from the associated SHA of the pipeline.
3811 3812 3813 3814 3815 3816 3817

For example, when creating a Release from a Git tag:

```yaml
job:
  release:
    tag_name: $CI_COMMIT_TAG
Jaime Martinez's avatar
Jaime Martinez committed
3818
    description: 'Release description'
3819 3820 3821 3822 3823 3824 3825 3826 3827
```

It is also possible to create any unique tag, in which case `only: tags` is not mandatory.
A semantic versioning example:

```yaml
job:
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
Jaime Martinez's avatar
Jaime Martinez committed
3828
    description: 'Release description'
3829 3830 3831 3832 3833 3834 3835 3836
```

- The Release is created only if the job's main script succeeds.
- If the Release already exists, it is not updated and the job with the `release` keyword fails.
- The `release` section executes after the `script` tag and before the `after_script`.

#### `release:name`

3837
The Release name. If omitted, it is populated with the value of `release: tag_name`.
3838 3839 3840

#### `release:description`

3841
Specifies the longer description of the Release.
3842 3843 3844

#### `release:ref`

3845 3846
If the `release: tag_name` doesn’t exist yet, the release is created from `ref`.
`ref` can be a commit SHA, another tag name, or a branch name.
3847 3848 3849 3850 3851 3852 3853

#### `release:milestones`

The title of each milestone the release is associated with.

#### `release:released_at`

3854
The date and time when the release is ready. Defaults to the current date and time if not
3855 3856 3857 3858 3859
defined. Should be enclosed in quotes and expressed in ISO 8601 format.

```json
released_at: '2021-03-15T08:00:00Z'
```
3860 3861 3862

#### Complete example for `release`

3863 3864 3865
Combining the individual examples given above for `release` results in the following
code snippets. There are two options, depending on how you generate the
tags. These options cannot be used together, so choose one:
3866

3867 3868
- To create a release when you push a Git tag, or when you add a Git tag
  in the UI by going to **Repository > Tags**:
3869

3870 3871 3872 3873 3874 3875 3876 3877 3878
  ```yaml
  release_job:
    stage: release
    image: registry.gitlab.com/gitlab-org/release-cli:latest
    rules:
      - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
    script:
      - echo 'running release_job'
    release:
Marcel Amirault's avatar
Marcel Amirault committed
3879 3880 3881 3882 3883 3884 3885 3886
      name: 'Release $CI_COMMIT_TAG'
      description: 'Created using the release-cli $EXTRA_DESCRIPTION'  # $EXTRA_DESCRIPTION must be defined
      tag_name: '$CI_COMMIT_TAG'                                       # elsewhere in the pipeline.
      ref: '$CI_COMMIT_TAG'
      milestones:
        - 'm1'
        - 'm2'
        - 'm3'
3887
      released_at: '2020-07-15T08:00:00Z'  # Optional, is auto generated if not defined, or can use a variable.
3888 3889
  ```

3890
- To create a release automatically when commits are pushed or merged to the default branch,
3891 3892
  using a new Git tag that is defined with variables:

Marcel Amirault's avatar
Marcel Amirault committed
3893 3894 3895 3896
  NOTE: **Note:**
  Environment variables set in `before_script` or `script` are not available for expanding
  in the same job. Read more about
  [potentially making variables available for expanding](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6400).
3897

3898
  ```yaml
3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911
  prepare_job:
    stage: prepare                                              # This stage must run before the release stage
    rules:
      - if: $CI_COMMIT_TAG
        when: never                                             # Do not run this job when a tag is created manually
      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH             # Run this job when commits are pushed or merged to the default branch
    script:
      - echo "EXTRA_DESCRIPTION=some message" >> variables.env  # Generate the EXTRA_DESCRIPTION and TAG environment variables
      - echo "TAG=v$(cat VERSION)" >> variables.env             # and append to the variables.env file
    artifacts:
      reports:
        dotenv: variables.env                                   # Use artifacts:reports:dotenv to expose the variables to other jobs

3912 3913 3914
  release_job:
    stage: release
    image: registry.gitlab.com/gitlab-org/release-cli:latest
3915
    needs:
Marcel Amirault's avatar
Marcel Amirault committed
3916 3917
      - job: prepare_job
        artifacts: true
3918 3919
    rules:
      - if: $CI_COMMIT_TAG
Marcel Amirault's avatar
Marcel Amirault committed
3920 3921
        when: never                                  # Do not run this job when a tag is created manually
      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  # Run this job when commits are pushed or merged to the default branch
3922
    script:
3923
      - echo 'running release_job for $TAG'
3924
    release:
Marcel Amirault's avatar
Marcel Amirault committed
3925 3926 3927 3928 3929 3930 3931 3932
      name: 'Release $TAG'
      description: 'Created using the release-cli $EXTRA_DESCRIPTION'  # $EXTRA_DESCRIPTION and the $TAG
      tag_name: '$TAG'                                                 # variables must be defined elsewhere
      ref: '$CI_COMMIT_SHA'                                            # in the pipeline. For example, in the
      milestones:                                                      # prepare_job
        - 'm1'
        - 'm2'
        - 'm3'
3933
      released_at: '2020-07-15T08:00:00Z'  # Optional, is auto generated if not defined, or can use a variable.
3934
  ```
3935

3936 3937 3938
#### Release assets as Generic packages

You can use [Generic packages](../../user/packages/generic_packages/) to host your release assets.
3939 3940
For a complete example, see the [Release assets as Generic packages](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs/examples/release-assets-as-generic-package/)
project.
3941

3942 3943
#### `releaser-cli` command line

3944
The entries under the `release` node are transformed into a `bash` command line and sent
3945 3946 3947
to the Docker container, which contains the [release-cli](https://gitlab.com/gitlab-org/release-cli).
You can also call the `release-cli` directly from a `script` entry.

3948
For example, using the YAML described above:
3949 3950

```shell
3951
release-cli create --name "Release $CI_COMMIT_SHA" --description "Created using the release-cli $EXTRA_DESCRIPTION" --tag-name "v${MAJOR}.${MINOR}.${REVISION}" --ref "$CI_COMMIT_SHA" --released-at "2020-07-15T08:00:00Z" --milestone "m1" --milestone "m2" --milestone "m3"
3952 3953
```

Krasimir Angelov's avatar
Krasimir Angelov committed
3954 3955 3956 3957 3958
### `secrets`

> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33014) in GitLab 13.4.

`secrets` indicates the [CI Secrets](../secrets/index.md) this job needs. It should be a hash,
Krasimir Angelov's avatar
Krasimir Angelov committed
3959 3960 3961
and the keys should be the names of the environment variables that are made available to the job.
The value of each secret is saved in a temporary file. This file's path is stored in these
environment variables.
Krasimir Angelov's avatar
Krasimir Angelov committed
3962 3963 3964 3965 3966 3967

#### `secrets:vault` **(PREMIUM)**

> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/28321) in GitLab 13.4.

`vault` keyword specifies secrets provided by [Hashicorp's Vault](https://www.vaultproject.io/).
Suzanne Selhorn's avatar
Suzanne Selhorn committed
3968
This syntax has multiple forms. The shortest form assumes the use of the
Krasimir Angelov's avatar
Krasimir Angelov committed
3969 3970 3971 3972 3973 3974 3975 3976
[KV-V2](https://www.vaultproject.io/docs/secrets/kv/kv-v2) secrets engine,
mounted at the default path `kv-v2`. The last part of the secret's path is the
field to fetch the value for:

```yaml
job:
  secrets:
    DATABASE_PASSWORD:
3977
      vault: production/db/password  # translates to secret `kv-v2/data/production/db`, field `password`
Krasimir Angelov's avatar
Krasimir Angelov committed
3978 3979 3980 3981 3982 3983 3984 3985
```

You can specify a custom secrets engine path by adding a suffix starting with `@`:

```yaml
job:
  secrets:
    DATABASE_PASSWORD:
3986
      vault: production/db/password@ops  # translates to secret `ops/data/production/db`, field `password`
Krasimir Angelov's avatar
Krasimir Angelov committed
3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002
```

In the detailed form of the syntax, you can specify all details explicitly:

```yaml
job:
  secrets:
    DATABASE_PASSWORD:      # translates to secret `ops/data/production/db`, field `password`
      vault:
        engine:
          name: kv-v2
          path: ops
        path: production/db
        field: password
```

Evan Read's avatar
Evan Read committed
4003
### `pages`
4004 4005 4006 4007 4008 4009 4010 4011

`pages` is a special job that is used to upload static content to GitLab that
can be used to serve your website. It has a special syntax, so the two
requirements below must be met:

- Any static content must be placed under a `public/` directory.
- `artifacts` with a path to the `public/` directory must be defined.

4012
The example below moves all files from the root of the project to the
Marcel Amirault's avatar
Marcel Amirault committed
4013
`public/` directory. The `.public` workaround is so `cp` does not also copy
4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030
`public/` to itself in an infinite loop:

```yaml
pages:
  stage: deploy
  script:
    - mkdir .public
    - cp -r * .public
    - mv .public public
  artifacts:
    paths:
      - public
  only:
    - master
```

Read more on [GitLab Pages user documentation](../../user/project/pages/index.md).
4031

4032
## `variables`
4033 4034 4035

> Introduced in GitLab Runner v0.5.0.

4036 4037
[CI/CD variables](../variables/README.md) are configurable values that are passed to jobs.
They can be set globally and per-job.
4038 4039 4040

There are two types of variables.

4041
- [Custom variables](../variables/README.md#custom-environment-variables):
4042 4043
  You can define their values in the `.gitlab-ci.yml` file, in the GitLab UI,
  or by using the API.
4044
- [Predefined variables](../variables/predefined_variables.md):
4045 4046
  These values are set by the runner itself.
  One example is `CI_COMMIT_REF_NAME`, which is the branch or tag the project is built for.
4047

4048
After you define a variable, you can use it in all executed commands and scripts.
4049

4050
Variables are meant for non-sensitive project configuration, for example:
4051 4052 4053

```yaml
variables:
4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066
  DEPLOY_SITE: "https://example.com/"

deploy_job:
  stage: deploy
  script:
    - deploy-script --url $DEPLOY_SITE --path "/"

deploy_review_job:
  stage: deploy
  variables:
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
4067 4068
```

4069
You can use only integers and strings for the variable's name and value.
4070 4071

If you define a variable at the top level of the `gitlab-ci.yml` file, it is global,
4072
meaning it applies to all jobs. If you define a variable in a job, it's available
4073
to that job only.
4074 4075 4076

If a variable of the same name is defined globally and for a specific job, the
[job-specific variable is used](../variables/README.md#priority-of-environment-variables).
4077

4078
All YAML-defined variables are also set to any linked
4079
[Docker service containers](../docker/using_docker_images.md#what-is-a-service).
4080

4081
You can use [YAML anchors for variables](#yaml-anchors-for-variables).
4082

4083
### Configure runner behavior with variables
4084

4085
You can use [CI/CD variables](../variables/README.md) to configure runner Git behavior:
4086

4087 4088 4089 4090 4091 4092 4093
- [`GIT_STRATEGY`](../runners/README.md#git-strategy)
- [`GIT_SUBMODULE_STRATEGY`](../runners/README.md#git-submodule-strategy)
- [`GIT_CHECKOUT`](../runners/README.md#git-checkout)
- [`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags)
- [`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags)
- [`GIT_DEPTH`](../runners/README.md#shallow-cloning) (shallow cloning)
- [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) (custom build directories)
4094

4095 4096
You can also use variables to configure how many times a runner
[attempts certain stages of job execution](../runners/README.md#job-stages-attempts).
4097

4098 4099 4100
## Special YAML features

It's possible to use special YAML features like anchors (`&`), aliases (`*`)
4101
and map merging (`<<`). Use these features to reduce the complexity
4102 4103 4104 4105
of `.gitlab-ci.yml`.

Read more about the various [YAML features](https://learnxinyminutes.com/docs/yaml/).

4106 4107 4108 4109
In most cases, the [`extends` keyword](#extends) is more user friendly and should
be used over these special YAML features. YAML anchors may still
need to be used to merge arrays.

4110 4111
### Anchors

4112 4113 4114 4115
YAML has a feature called 'anchors' that you can use to duplicate
content across your document.

Use anchors to duplicate or inherit properties. Use anchors with [hidden jobs](#hide-jobs)
Suzanne Selhorn's avatar
Suzanne Selhorn committed
4116 4117
to provide templates for your jobs. When there are duplicate keys, GitLab
performs a reverse deep merge based on the keys.
4118

4119
You can't use YAML anchors across multiple files when leveraging the [`include`](#include)
4120
feature. Anchors are only valid in the file they were defined in. Instead
4121 4122
of using YAML anchors, you can use the [`extends` keyword](#extends).

Suzanne Selhorn's avatar
Suzanne Selhorn committed
4123
The following example uses anchors and map merging. It creates two jobs,
4124
`test1` and `test2`, that inherit the `.job_template` configuration, each
Suzanne Selhorn's avatar
Suzanne Selhorn committed
4125
with their own custom `script` defined:
4126 4127

```yaml
4128
.job_template: &job_definition  # Hidden key that defines an anchor named 'job_definition'
4129
  image: ruby:2.6
4130 4131 4132 4133 4134
  services:
    - postgres
    - redis

test1:
4135
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
4136
  script:
4137
    - test1 project
4138 4139

test2:
4140
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
4141
  script:
4142 4143 4144 4145 4146
    - test2 project
```

`&` sets up the name of the anchor (`job_definition`), `<<` means "merge the
given hash into the current one", and `*` includes the named anchor
4147
(`job_definition` again). The expanded version of the example above is:
4148 4149 4150

```yaml
.job_template:
4151
  image: ruby:2.6
4152 4153 4154 4155 4156
  services:
    - postgres
    - redis

test1:
4157
  image: ruby:2.6
4158 4159 4160 4161 4162 4163 4164
  services:
    - postgres
    - redis
  script:
    - test1 project

test2:
4165
  image: ruby:2.6
4166 4167 4168 4169 4170
  services:
    - postgres
    - redis
  script:
    - test2 project
4171 4172
```

4173 4174 4175
You can use anchors to define two sets of services. For example, `test:postgres`
and `test:mysql` share the `script` defined in `.job_template`, but use different
`services`, defined in `.postgres_services` and `.mysql_services`:
4176 4177 4178 4179 4180

```yaml
.job_template: &job_definition
  script:
    - test project
4181 4182
  tags:
    - dev
4183 4184 4185 4186 4187 4188

.postgres_services:
  services: &postgres_definition
    - postgres
    - ruby

4189
.mysql_services:
4190 4191 4192 4193 4194
  services: &mysql_definition
    - mysql
    - ruby

test:postgres:
Achilleas Pipinellis's avatar
Achilleas Pipinellis committed
4195
  <<: *job_definition
4196
  services: *postgres_definition
4197 4198
  tags:
    - postgres
4199 4200

test:mysql:
Achilleas Pipinellis's avatar
Achilleas Pipinellis committed
4201
  <<: *job_definition
4202 4203 4204
  services: *mysql_definition
```

4205
The expanded version is:
4206

4207 4208 4209 4210
```yaml
.job_template:
  script:
    - test project
4211 4212
  tags:
    - dev
4213

4214 4215 4216 4217
.postgres_services:
  services:
    - postgres
    - ruby
4218

4219 4220 4221 4222 4223 4224
.mysql_services:
  services:
    - mysql
    - ruby

test:postgres:
4225
  script:
4226 4227 4228 4229
    - test project
  services:
    - postgres
    - ruby
4230 4231
  tags:
    - postgres
4232 4233 4234 4235 4236 4237 4238

test:mysql:
  script:
    - test project
  services:
    - mysql
    - ruby
4239 4240
  tags:
    - dev
4241 4242
```

4243 4244
You can see that the hidden jobs are conveniently used as templates, and
`tags: [dev]` has been overwritten by `tags: [postgres]`.
4245

4246
#### YAML anchors for scripts
4247

4248
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23005) in GitLab 12.5.
4249

4250 4251
You can use [YAML anchors](#anchors) with [script](#script), [`before_script`](#before_script),
and [`after_script`](#after_script) to use predefined commands in multiple jobs:
4252 4253

```yaml
4254
.some-script: &some-script
4255
  - echo "Execute this script in `before_script` sections"
4256

4257
.some-script-before: &some-script-before
4258
  - echo "Execute this script in `script` sections"
4259

4260
.some-script-after: &some-script-after
4261
  - echo "Execute this script in `after_script` sections"
4262 4263

job_name:
4264 4265
  before_script:
    - *some-script-before
4266
  script:
4267 4268 4269
    - *some-script
  before_script:
    - *some-script-after
4270 4271 4272 4273
```

#### YAML anchors for variables

4274 4275
[YAML anchors](#anchors) can be used with `variables`, to repeat assignment
of variables across multiple jobs. Use can also use YAML anchors when a job
4276 4277
requires a specific `variables` block that would otherwise override the global variables.

Suzanne Selhorn's avatar
Suzanne Selhorn committed
4278
In the example below, we override the `GIT_STRATEGY` variable without affecting
4279 4280 4281 4282 4283 4284
the use of the `SAMPLE_VARIABLE` variable:

```yaml
# global variables
variables: &global-variables
  SAMPLE_VARIABLE: sample_variable_value
4285
  ANOTHER_SAMPLE_VARIABLE: another_sample_variable_value
4286

Suzanne Selhorn's avatar
Suzanne Selhorn committed
4287
# a job that must set the GIT_STRATEGY variable, yet depend on global variables
4288 4289 4290 4291 4292 4293 4294 4295
job_no_git_strategy:
  stage: cleanup
  variables:
    <<: *global-variables
    GIT_STRATEGY: none
  script: echo $SAMPLE_VARIABLE
```

4296
### Hide jobs
4297

4298 4299
If you want to temporarily 'disable' a job, rather than commenting out all the
lines where the job is defined:
Evan Read's avatar
Evan Read committed
4300

4301
```yaml
Marcel Amirault's avatar
Marcel Amirault committed
4302 4303 4304
# hidden_job:
#   script:
#     - run test
4305
```
4306

Suzanne Selhorn's avatar
Suzanne Selhorn committed
4307 4308
Instead, you can start its name with a dot (`.`) and it is not processed by
GitLab CI/CD. In the following example, `.hidden_job` is ignored:
4309 4310 4311 4312 4313 4314 4315 4316

```yaml
.hidden_job:
  script:
    - run test
```

Use this feature to ignore jobs, or use the
4317
[special YAML features](#special-yaml-features) and transform the hidden jobs
4318 4319 4320 4321 4322
into templates.

## Skip Pipeline

If your commit message contains `[ci skip]` or `[skip ci]`, using any
Suzanne Selhorn's avatar
Suzanne Selhorn committed
4323
capitalization, the commit is created but the pipeline is skipped.
4324 4325 4326

Alternatively, one can pass the `ci.skip` [Git push option](../../user/project/push_options.md#push-options-for-gitlab-cicd)
if using Git 2.10 or newer.
4327

4328 4329
## Processing Git pushes

Suzanne Selhorn's avatar
Suzanne Selhorn committed
4330
GitLab creates at most four branch and tag pipelines when
4331
pushing multiple changes in a single `git push` invocation.
4332

Suzanne Selhorn's avatar
Suzanne Selhorn committed
4333 4334
This limitation does not affect any of the updated merge request pipelines.
All updated merge requests have a pipeline created when using
4335 4336
[pipelines for merge requests](../merge_request_pipelines/index.md).

4337
## Deprecated keywords
4338

4339
The following keywords are deprecated.
4340

4341 4342
### Globally-defined `types`

4343
DANGER: **Deprecated:**
4344 4345 4346 4347 4348
`types` is deprecated, and could be removed in a future release.
Use [`stages`](#stages) instead.

### Job-defined `type`

4349
DANGER: **Deprecated:**
4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372
`type` is deprecated, and could be removed in one of the future releases.
Use [`stage`](#stage) instead.

### Globally-defined `image`, `services`, `cache`, `before_script`, `after_script`

Defining `image`, `services`, `cache`, `before_script`, and
`after_script` globally is deprecated. Support could be removed
from a future release.

Use [`default:`](#global-defaults) instead. For example:

```yaml
default:
  image: ruby:2.5
  services:
    - docker:dind
  cache:
    paths: [vendor/]
  before_script:
    - bundle install --path vendor/
  after_script:
    - rm -rf tmp/
```
4373

Marcia Ramos's avatar
Marcia Ramos committed
4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384
<!-- ## Troubleshooting

Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.

Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->