@ -34,8 +34,8 @@ We have complete examples of configuring pipelines:
> from 30 days to under 8 hours with GitLab.
NOTE: **Note:**
If you have a [mirrored repository where GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter),
you may need to enable pipeline triggering in your project's
If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter),
you may need to enable pipeline triggering. Go to your project's
**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
## Introduction
@ -63,8 +63,8 @@ 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.
Jobs are picked up by [Runners](../runners/README.md) and executed within the
environment of the Runner. What is important, is that each job is run
Jobs are 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.
### Validate the `.gitlab-ci.yml`
@ -103,7 +103,7 @@ The following table lists available parameters for jobs:
| [`script`](#script) | Shell script which is executed by Runner. |
| [`script`](#script) | Shell script that is executed by a runner. |
| [`after_script`](#before_script-and-after_script) | Override a set of commands that are executed after job. |
| [`allow_failure`](#allow_failure) | Allow job to fail. Failed job does not contribute to commit status. |
| [`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`, `artifacts:reports`. |
@ -113,20 +113,20 @@ The following table lists available parameters for jobs:
| [`dependencies`](#dependencies) | Restrict which artifacts are passed to a specific job by providing a list of jobs to fetch artifacts from. |
| [`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`. |
| [`except`](#onlyexcept-basic) | Limit when jobs are not created. Also available: [`except:refs`, `except:kubernetes`, `except:variables`, and `except:changes`](#onlyexcept-advanced). |
| [`extends`](#extends) | Configuration entries that this job is going to inherit from. |
| [`extends`](#extends) | Configuration entries that this job inherits from. |
| [`image`](#image) | Use Docker images. Also available: `image:name` and `image:entrypoint`. |
| [`include`](#include) | Allows this job to include external YAML files. Also available: `include:local`, `include:file`, `include:template`, and `include:remote`. |
| [`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. |
| [`release`](#release) | Instructs the Runner to generate a [Release](../../user/project/releases/index.md) object. |
| [`release`](#release) | Instructs the runner to generate a [Release](../../user/project/releases/index.md) object. |
| [`retry`](#retry) | When and how many times a job can be auto-retried in case of a failure. |
| [`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`. |
| [`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`). |
| [`tags`](#tags) | List of tags which are used to select Runner. |
| [`tags`](#tags) | List of tags that are used to select a runner. |
| [`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. |
@ -290,14 +290,14 @@ There are also two edge cases worth mentioning:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29654) in GitLab 12.5
The top-level `workflow:` key applies to the entirety of a pipeline, and will
determine whether or not a pipeline is created. It currently accepts a single
The top-level `workflow:` key applies to the entirety of a pipeline, and
determines whether or not a pipeline is created. It accepts a single
`rules:` key that operates similarly to [`rules:` defined within jobs](#rules),
enabling dynamic configuration of the pipeline.
If you are new to GitLab CI/CD and `workflow: rules`, you may find the [`workflow:rules` templates](#workflowrules-templates) useful.
To define your own `workflow: rules`, the configuration options currently available are:
To define your own `workflow: rules`, the available configuration options are:
- [`if`](#rulesif): Define a rule.
- [`when`](#when): May be set to `always` or `never` only. If not provided, the default value is `always`.
@ -315,8 +315,8 @@ the [common `if` clauses for `rules`](#common-if-clauses-for-rules) for more exa
| `if: $CI_COMMIT_TAG` | Control when tag pipelines run. |
| `if: $CI_COMMIT_BRANCH` | Control when branch pipelines run. |
For example, with the following configuration, pipelines run for all `push` events (changes to
branches and new tags) as long as they *don't* have `-wip` in the commit message. Scheduled
For example, in the following configuration, pipelines run for all `push` events (changes to
branches and new tags). Only push events with `-wip` in the commit message are excluded. Scheduled
pipelines and merge request pipelines don't run, as there's no rule allowing them.
```yaml
@ -399,7 +399,7 @@ It's also possible to have template files stored in a central repository and pro
configuration files. This helps avoid duplicated configuration, for example, global default variables for all projects.
`include` requires the external YAML file to have the extensions `.yml` or `.yaml`,
otherwise the external file won't be included.
otherwise the external file is not included.
`include` supports the following inclusion methods:
@ -408,14 +408,14 @@ otherwise the external file won't be included.
| [`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. |
| [`template`](#includetemplate) | Include templates which are provided by GitLab. |
| [`template`](#includetemplate) | Include templates that are provided by GitLab. |
The `include` methods do not support [variable expansion](../variables/where_variables_can_be_used.md#variables-usage).
NOTE: **Note:**
`.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
referenced `.gitlab-ci.yml` configuration won't be reflected in GitLab until the next pipeline is created.
referenced `.gitlab-ci.yml` configuration is not reflected in GitLab until the next pipeline is created.
The files defined by `include` are:
@ -425,7 +425,7 @@ The files defined by `include` are:
TIP: **Tip:**
Use merging to customize and override included CI/CD configurations with local
definitions. Local definitions in `.gitlab-ci.yml` will override included definitions.
definitions. Local definitions in `.gitlab-ci.yml` override included definitions.
NOTE: **Note:**
Using [YAML anchors](#anchors) across different YAML files sourced by `include` is not
@ -437,11 +437,11 @@ of using YAML anchors, you can use the [`extends` keyword](#extends).
`include:local` includes a file from the same repository as `.gitlab-ci.yml`.
It's referenced using full paths relative to the root directory (`/`).
You can only use files that are currently tracked by Git on the same branch
You can only use files that are tracked by Git on the same branch
your configuration file is on. In other words, when using a `include:local`, make
sure that both `.gitlab-ci.yml` and the local file are on the same branch.
All [nested includes](#nested-includes) will be executed in the scope of the same project,
All [nested includes](#nested-includes) are executed in the scope of the same project,
so it's possible to use local, project, remote, or template includes.
NOTE: **Note:**
@ -455,7 +455,7 @@ include:
```
TIP: **Tip:**
Local includes can be used as a replacement for symbolic links which are not followed.
Local includes can be used as a replacement for symbolic links that are not followed.
This can be defined as a short local include:
@ -494,7 +494,7 @@ include:
file: '/templates/.gitlab-ci-template.yml'
```
All [nested includes](#nested-includes) will be executed in the scope of the target project,
All [nested includes](#nested-includes) are executed in the scope of the target project,
so it's possible to use local (relative to target project), project, remote
GitLab Bot