BigW Consortium Gitlab

README.md 18.8 KB
Newer Older
1 2
# Configuration of your builds with .gitlab-ci.yml

3 4 5 6 7 8 9
From version 7.12, GitLab CI uses a [YAML](https://en.wikipedia.org/wiki/YAML)
file (`.gitlab-ci.yml`) for the project configuration. It is placed in the root
of your repository and contains definitions of how your project should be built.

The YAML file defines a set of jobs with constraints stating when they should
be run. The jobs are defined as top-level elements with a name and always have
to contain the `script` clause:
10 11 12 13 14 15 16 17 18

```yaml
job1:
  script: "execute-script-for-job1"

job2:
  script: "execute-script-for-job2"
```

19 20 21 22 23
The above example is the simplest possible CI configuration with two separate
jobs, where each of the jobs executes a different command.

Of course a command can execute code directly (`./configure;make;make install`)
or run a script (`test.sh`) in the repository.
24

25 26 27 28
Jobs are used to create builds, which are then picked up by
[runners](../runners/README.md) and executed within the environment of the
runner. What is important, is that each job is run independently from each
other.
29 30

## .gitlab-ci.yml
31 32 33

The YAML syntax allows for using more complex job specifications than in the
above example:
34 35

```yaml
James Lopez committed
36
image: ruby:2.1
37 38 39 40
services:
  - postgres

before_script:
frodsan committed
41
  - bundle install
42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  script:
    - execute-script-for-job1
  only:
    - master
  tags:
    - docker
```

58
There are a few reserved `keywords` that **cannot** be used as job names:
59

60
| Keyword       | Required | Description |
61
|---------------|----------|-------------|
62 63 64 65 66 67 68
| image         | no | Use docker image, covered in [Use Docker](../docker/README.md) |
| services      | no | Use docker services, covered in [Use Docker](../docker/README.md) |
| stages        | no | Define build stages |
| types         | no | Alias for `stages` |
| before_script | no | Define commands that run before each job's script |
| variables     | no | Define build variables |
| cache         | no | Define list of files that should be cached between subsequent runs |
69 70

### image and services
71 72 73 74

This allows to specify a custom Docker image and a list of services that can be
used for time of the build. The configuration of this feature is covered in
separate document: [Use Docker](../docker/README.md).
75 76

### before_script
77 78 79

`before_script` is used to define the command that should be run before all
builds, including deploy builds. This can be an array or a multi-line string.
80 81

### stages
82

83 84 85 86 87 88 89 90 91
`stages` is used to define build stages that can be used by jobs.
The specification of `stages` allows for having flexible multi stage pipelines.

The ordering of elements in `stages` defines the ordering of builds' execution:

1. Builds of the same stage are run in parallel.
1. Builds of next stage are run after success.

Let's consider the following example, which defines 3 stages:
92 93

```yaml
94 95 96 97 98 99 100 101 102 103
stages:
  - build
  - test
  - deploy
```

1. First all jobs of `build` are executed in parallel.
1. If all jobs of `build` succeeds, the `test` jobs are executed in parallel.
1. If all jobs of `test` succeeds, the `deploy` jobs are executed in parallel.
1. If all jobs of `deploy` succeeds, the commit is marked as `success`.
104 105
1. If any of the previous jobs fails, the commit is marked as `failed` and no
   jobs of further stage are executed.
106 107 108

There are also two edge cases worth mentioning:

109 110
1. If no `stages` is defined in `.gitlab-ci.yml`, then by default the `build`,
   `test` and `deploy` are allowed to be used as job's stage by default.
111 112 113
2. If a job doesn't specify `stage`, the job is assigned the `test` stage.

### types
114

115 116 117 118
Alias for [stages](#stages).

### variables

119 120
>**Note:**
Introduced in GitLab Runner v0.5.0.
121 122 123 124

GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in build
environment. The variables are stored in the git repository and are meant to
store non-sensitive project configuration, for example:
125 126 127 128 129 130 131 132

```yaml
variables:
  DATABASE_URL: "postgres://postgres@postgres/my_database"
```

These variables can be later used in all executed commands and scripts.

133 134
The YAML-defined variables are also set to all created service containers,
thus allowing to fine tune them.
135

136 137
### cache

138 139 140
>**Note:**
Introduced in GitLab Runner v0.7.0.

141
`cache` is used to specify a list of files and directories which should be
142 143 144
cached between builds.

**By default the caching is enabled per-job and per-branch.**
145 146 147

If `cache` is defined outside the scope of the jobs, it means it is set
globally and all jobs will use its definition.
148

149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181
Cache all files in `binaries` and `.config`:

```yaml
rspec:
  script: test
  cache:
    paths:
    - binaries/
    - .config
```

Cache all Git untracked files:

```yaml
rspec:
  script: test
  cache:
    untracked: true
```

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

```yaml
rspec:
  script: test
  cache:
    untracked: true
    paths:
    - binaries/
```

Locally defined cache overwrites globally defined options. This will cache only
`binaries/`:
182 183

```yaml
184 185
cache:
  paths:
186 187 188 189 190 191 192
  - my/files

rspec:
  script: test
  cache:
    paths:
    - binaries/
193 194
```

195 196 197
The cache is provided on best effort basis, so don't expect that cache will be
always present. For implementation details please check GitLab Runner.

198 199
#### cache:key

200 201
>**Note:**
Introduced in GitLab Runner v1.0.0.
202 203 204 205 206

The `key` directive allows you to define the affinity of caching
between jobs, allowing to have a single cache for all jobs,
cache per-job, cache per-branch or any other way you deem proper.

207 208
This allows you to fine tune caching, allowing you to cache data between
different jobs or even different branches.
209

210 211 212 213 214
The `cache:key` variable can use any of the [predefined variables](../variables/README.md).

---

**Example configurations**
215 216 217

To enable per-job caching:

218 219 220 221 222
```yaml
cache:
  key: "$CI_BUILD_NAME"
  untracked: true
```
223 224 225

To enable per-branch caching:

226 227 228 229 230
```yaml
cache:
  key: "$CI_BUILD_REF_NAME"
  untracked: true
```
231 232 233

To enable per-job and per-branch caching:

234 235 236 237 238
```yaml
cache:
  key: "$CI_BUILD_NAME/$CI_BUILD_REF_NAME"
  untracked: true
```
239 240 241

To enable per-branch and per-stage caching:

242 243 244 245 246
```yaml
cache:
  key: "$CI_BUILD_STAGE/$CI_BUILD_REF_NAME"
  untracked: true
```
247

248 249
If you use **Windows Batch** to run your shell scripts you need to replace
`$` with `%`:
250

251 252 253 254 255
```yaml
cache:
  key: "%CI_BUILD_STAGE%/%CI_BUILD_REF_NAME%"
  untracked: true
```
256

257
## Jobs
258 259 260 261

`.gitlab-ci.yml` allows you to specify an unlimited number of jobs. Each job
must have a unique name, which is not one of the Keywords mentioned above.
A job is defined by a list of parameters that define the build behavior.
262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278

```yaml
job_name:
  script:
    - rake spec
    - coverage
  stage: test
  only:
    - master
  except:
    - develop
  tags:
    - ruby
    - postgres
  allow_failure: true
```

279
| Keyword       | Required | Description |
280
|---------------|----------|-------------|
281
| script        | yes | Defines a shell script which is executed by runner |
Pat Turner committed
282 283
| image         | no | Use docker image, covered in [Using Docker Images](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml) |
| services      | no | Use docker services, covered in [Using Docker Images](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml) |
284
| stage         | no | Defines a build stage (default: `test`) |
285 286 287 288 289 290
| type          | no | Alias for `stage` |
| only          | no | Defines a list of git refs for which build is created |
| except        | no | Defines a list of git refs for which build is not created |
| tags          | no | Defines a list of tags which are used to select runner |
| allow_failure | no | Allow build to fail. Failed build doesn't contribute to commit status |
| when          | no | Define when to run build. Can be `on_success`, `on_failure` or `always` |
291
| dependencies  | no | Define other builds that a build depends on so that you can pass artifacts between them|
292 293
| artifacts     | no | Define list build artifacts |
| cache         | no | Define list of files that should be cached between subsequent runs |
294 295

### script
296 297

`script` is a shell script which is executed by the runner. For example:
298 299 300 301 302 303 304

```yaml
job:
  script: "bundle exec rspec"
```

This parameter can also contain several commands using an array:
305

306 307 308 309 310 311 312 313
```yaml
job:
  script:
    - uname -a
    - bundle exec rspec
```

### stage
314 315 316 317

`stage` allows to group build into different stages. Builds of the same `stage`
are executed in `parallel`. For more info about the use of `stage` please check
[stages](#stages).
318 319 320

### only and except

321 322
`only` and `except` are two parameters that set a refs policy to limit when
jobs are built:
323

324 325 326 327 328 329 330 331 332 333
1. `only` defines the names of branches and tags for which the job will be
    built.
2. `except` defines the names of branches and tags for which the job will
    **not** be built.

There are a few rules that apply to the usage of refs policy:

* `only` and `except` are inclusive. If both `only` and `except` are defined
   in a job specification, the ref is filtered by `only` and `except`.
* `only` and `except` allow the use of regular expressions.
334
* `only` and `except` allow the use of special keywords: `branches`, `tags`, and `triggers`.
335 336 337 338 339
* `only` and `except` allow to specify a repository path to filter jobs for
   forks.

In the example below, `job` will run only for refs that start with `issue-`,
whereas all branches will be skipped.
340 341 342

```yaml
job:
343
  # use regexp
344
  only:
345 346
    - /^issue-.*$/
  # use special keyword
347
  except:
348
    - branches
349 350
```

351 352 353 354 355 356 357 358 359 360 361
In this example, `job` will run only for refs that are tagged, or if a build is explicitly requested
via an API trigger.

```yaml
job:
  # use special keywords
  only:
    - tags
    - triggers
```

362 363
The repository path can be used to have jobs executed only for the parent
repository and not forks:
364 365 366 367 368 369 370 371

```yaml
job:
  only:
    - branches@gitlab-org/gitlab-ce
  except:
    - master@gitlab-org/gitlab-ce
```
372 373 374

The above example will run `job` for all branches on `gitlab-org/gitlab-ce`,
except master.
375

376 377
### tags

378 379
`tags` is used to select specific runners from the list of all runners that are
allowed to run this project.
380

381 382 383 384 385 386 387
During the registration of a runner, you can specify the runner's tags, for
example `ruby`, `postgres`, `development`.

`tags` allow you to run builds with runners that have the specified tags
assigned to them:

```yaml
388 389 390 391 392 393
job:
  tags:
    - ruby
    - postgres
```

394 395
The specification above, will make sure that `job` is built by a runner that
has both `ruby` AND `postgres` tags defined.
396

397
### when
398 399 400

`when` is used to implement jobs that are run in case of failure or despite the
failure.
401

Robert Speicher committed
402 403
`when` can be set to one of the following values:

404 405 406 407
1. `on_success` - execute build only when all builds from prior stages
    succeeded. This is the default.
1. `on_failure` - execute build only when at least one build from prior stages
    failed.
408 409
1. `always` - execute build despite the status of builds from prior stages.

410 411 412
For example:

```yaml
413 414 415 416 417 418 419
stages:
- build
- cleanup_build
- test
- deploy
- cleanup

420
build_job:
421 422 423 424
  stage: build
  script:
  - make build

425
cleanup_build_job:
426 427 428 429 430
  stage: cleanup_build
  script:
  - cleanup build when failed
  when: on_failure

431
test_job:
432 433 434 435
  stage: test
  script:
  - make test

436
deploy_job:
437 438 439 440
  stage: deploy
  script:
  - make deploy

441
cleanup_job:
442 443 444 445 446 447 448
  stage: cleanup
  script:
  - cleanup after builds
  when: always
```

The above script will:
449 450 451

1. Execute `cleanup_build_job` only when `build_job` fails
2. Always execute `cleanup_job` as the last step in pipeline.
452

453 454
### artifacts

455 456 457
>**Notes:**
>
> - Introduced in GitLab Runner v0.7.0 for non-Windows platforms.
458
> - Windows support was added in GitLab Runner v.1.0.0.
459 460
> - Currently not all executors are supported.
> - Build artifacts are only collected for successful builds.
461

462
`artifacts` is used to specify list of files and directories which should be
463 464 465 466
attached to build after success. To pass artifacts between different builds,
see [dependencies](#dependencies).

Below are some examples.
467

468
Send all files in `binaries` and `.config`:
469

470 471 472 473 474 475
```yaml
artifacts:
  paths:
  - binaries/
  - .config
```
476

477
Send all Git untracked files:
478

479 480 481 482 483
```yaml
artifacts:
  untracked: true
```

484
Send all Git untracked files and files in `binaries`:
485

486 487 488 489 490 491
```yaml
artifacts:
  untracked: true
  paths:
  - binaries/
```
492

493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514
You may want to create artifacts only for tagged releases to avoid filling the
build server storage with temporary build artifacts.

Create artifacts only for tags (`default-job` will not create artifacts):

```yaml
default-job:
  script:
    - mvn test -U
  except:
    - tags

release-job:
  script:
    - mvn package -U
  artifacts:
    paths:
    - target/*.war
  only:
    - tags
```

515 516
The artifacts will be sent to GitLab after a successful build and will
be available for download in the GitLab UI.
517

518 519
#### artifacts:name

520 521
>**Note:**
Introduced in GitLab 8.6 and GitLab Runner v1.1.0.
522

523 524 525 526
The `name` directive allows you to define the name of the created artifacts
archive. That way, you can have a unique name of every archive which could be
useful when you'd like to download the archive from GitLab. The `artifacts:name`
variable can make use of any of the [predefined variables](../variables/README.md).
527 528 529 530 531

---

**Example configurations**

532
To create an archive with a name of the current build:
533 534 535 536 537 538 539

```yaml
job:
  artifacts:
    name: "$CI_BUILD_NAME"
```

540 541
To create an archive with a name of the current branch or tag including only
the files that are untracked by Git:
542 543 544 545 546 547 548 549

```yaml
job:
   artifacts:
     name: "$CI_BUILD_REF_NAME"
     untracked: true
```

550 551
To create an archive with a name of the current build and the current branch or
tag including only the files that are untracked by Git:
552 553 554 555 556 557 558 559

```yaml
job:
  artifacts:
    name: "${CI_BUILD_NAME}_${CI_BUILD_REF_NAME}"
    untracked: true
```

560
To create an archive with a name of the current [stage](#stages) and branch name:
561 562 563 564 565 566 567 568

```yaml
job:
  artifacts:
    name: "${CI_BUILD_STAGE}_${CI_BUILD_REF_NAME}"
    untracked: true
```

569 570
---

571 572 573 574 575 576 577 578 579 580
If you use **Windows Batch** to run your shell scripts you need to replace
`$` with `%`:

```yaml
job:
  artifacts:
    name: "%CI_BUILD_STAGE%_%CI_BUILD_REF_NAME%"
    untracked: true
```

581 582
### dependencies

583 584
>**Note:**
Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
585

586 587
This feature should be used in conjunction with [`artifacts`](#artifacts) and
allows you to define the artifacts to pass between different builds.
588

589
Note that `artifacts` from previous [stages](#stages) are passed by default.
590

591
To use this feature, define `dependencies` in context of the job and pass
592
a list of all previous builds from which the artifacts should be downloaded.
593 594 595 596
You can only define builds from stages that are executed before the current one.
An error will be shown if you define builds from the current stage or next ones.

---
597

598 599 600 601 602 603 604
In the following example, we define two jobs with artifacts, `build:osx` and
`build:linux`. When the `test:osx` is executed, the artifacts from `build:osx`
will be downloaded and extracted in the context of the build. The same happens
for `test:linux` and artifacts from `build:linux`.

The job `deploy` will download artifacts from all previous builds because of
the [stage](#stages) precedence:
605

606
```yaml
607 608
build:osx:
  stage: build
609
  script: make build:osx
610 611 612
  artifacts:
    paths:
    - binaries/
613

614 615
build:linux:
  stage: build
616
  script: make build:linux
617 618 619 620 621 622
  artifacts:
    paths:
    - binaries/

test:osx:
  stage: test
623
  script: make test:osx
624 625 626 627 628
  dependencies:
  - build:osx

test:linux:
  stage: test
629
  script: make test:linux
630 631 632 633 634
  dependencies:
  - build:linux

deploy:
  stage: deploy
635
  script: make deploy
636 637
```

Achilleas Pipinellis committed
638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655
## Hidden jobs

>**Note:**
Introduced in GitLab 8.6 and GitLab Runner v1.1.1.

Jobs that start with a dot (`.`) will be not processed by GitLab CI. You can
use this feature to ignore jobs, or use the
[special YAML features](#special-yaml-features) and transform the hidden jobs
into templates.

In the following example, `.job_name` will be ignored:

```yaml
.job_name:
  script:
    - rake spec
```

656
## Special YAML features
657

658 659 660
It's possible to use special YAML features like anchors (`&`), aliases (`*`)
and map merging (`<<`), which will allow you to greatly reduce the complexity
of `.gitlab-ci.yml`.
661

662
Read more about the various [YAML features](https://learnxinyminutes.com/docs/yaml/).
663

664 665 666 667 668 669 670 671 672 673 674 675 676
### Anchors

>**Note:**
Introduced in GitLab 8.6 and GitLab Runner v1.1.1.

YAML also has a handy feature called 'anchors', which let you easily duplicate
content across your document. Anchors can be used to duplicate/inherit
properties, and is a perfect example to be used with [hidden jobs](#hidden-jobs)
to provide templates for your jobs.

The following example uses anchors and map merging. It will create two jobs,
`test1` and `test2`, that will inherit the parameters of `.job_template`, each
having their own custom `script` defined:
677 678

```yaml
679
.job_template: &job_definition  # Hidden job that defines an anchor named 'job_definition'
680 681 682 683 684 685
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
686
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
687
  script:
688
    - test1 project
689 690

test2:
691
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
692
  script:
693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721
    - 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
(`job_definition` again). The expanded version looks like this:

```yaml
.job_template:
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  image: ruby:2.1
  services:
    - postgres
    - redis
  script:
    - test1 project

test2:
  image: ruby:2.1
  services:
    - postgres
    - redis
  script:
    - test2 project
722 723
```

724 725 726 727
Let's see another one example. This time we will use anchors to define two sets
of services. This will create two jobs, `test:postgres` and `test:mysql`, that
will share the `script` directive defined in `.job_template`, and the `services`
directive defined in `.postgres_services` and `.mysql_services` respectively:
728 729 730 731 732 733 734 735 736 737 738

```yaml
.job_template: &job_definition
  script:
    - test project

.postgres_services:
  services: &postgres_definition
    - postgres
    - ruby

739
.mysql_services:
740 741 742 743 744 745 746 747 748 749 750 751 752
  services: &mysql_definition
    - mysql
    - ruby

test:postgres:
  << *job_definition
  services: *postgres_definition

test:mysql:
  << *job_definition
  services: *mysql_definition
```

753
The expanded version looks like this:
754

755 756 757 758
```yaml
.job_template:
  script:
    - test project
759

760 761 762 763
.postgres_services:
  services:
    - postgres
    - ruby
764

765 766 767 768 769 770
.mysql_services:
  services:
    - mysql
    - ruby

test:postgres:
771
  script:
772 773 774 775 776 777 778 779 780 781 782
    - test project
  services:
    - postgres
    - ruby

test:mysql:
  script:
    - test project
  services:
    - mysql
    - ruby
783 784
```

785
You can see that the hidden jobs are conveniently used as templates.
786

787
## Validate the .gitlab-ci.yml
788

789
Each instance of GitLab CI has an embedded debug tool called Lint.
790
You can find the link under `/ci/lint` of your gitlab instance.
791 792

## Skipping builds
793 794 795

If your commit message contains `[ci skip]`, the commit will be created but the
builds will be skipped.
796 797 798 799 800 801 802

## Examples

Visit the [examples README][examples] to see a list of examples using GitLab
CI with various languages.

[examples]: ../examples/README.md