Skip to content

G
gitlab-ce
Commit cb512a13 authored by Marcel Amirault's avatar Marcel Amirault Committed by Kati Paizee
Browse files
Options

Remove extra colons from keywords

parent 7266d8f4
Hide whitespace changes
Inline Side-by-side
Showing with 90 additions and 90 deletions
doc/administration/cicd.md
View file @ cb512a13
...@@ -58,9 +58,9 @@ For Omnibus GitLab installations: ...@@ -58,9 +58,9 @@ For Omnibus GitLab installations:
sudo gitlab-ctl reconfigure sudo gitlab-ctl reconfigure
``` ```
## Set the `needs:` job limit **(FREE SELF)** ## Set the `needs` job limit **(FREE SELF)**
The maximum number of jobs that can be defined in `needs:` defaults to 50. The maximum number of jobs that can be defined in `needs` defaults to 50.
A GitLab administrator with [access to the GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session) A GitLab administrator with [access to the GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session)
can choose a custom limit. For example, to set the limit to `100`: can choose a custom limit. For example, to set the limit to `100`:
......
doc/ci/caching/index.md
View file @ cb512a13
...@@ -27,7 +27,7 @@ can't link to files outside it. ...@@ -27,7 +27,7 @@ can't link to files outside it.
### Cache ### Cache
- Define cache per job by using the `cache:` keyword. Otherwise it is disabled. - Define cache per job by using the `cache` keyword. Otherwise it is disabled.
- Subsequent pipelines can use the cache. - Subsequent pipelines can use the cache.
- Subsequent jobs in the same pipeline can use the cache, if the dependencies are identical. - Subsequent jobs in the same pipeline can use the cache, if the dependencies are identical.
- Different projects cannot share the cache. - Different projects cannot share the cache.
......
doc/ci/directed_acyclic_graph/index.md
View file @ cb512a13
...@@ -66,9 +66,9 @@ as quickly as possible. ...@@ -66,9 +66,9 @@ as quickly as possible.
## Usage ## Usage
Relationships are defined between jobs using the [`needs:` keyword](../yaml/index.md#needs). Relationships are defined between jobs using the [`needs` keyword](../yaml/index.md#needs).
Note that `needs:` also works with the [parallel](../yaml/index.md#parallel) keyword, Note that `needs` also works with the [parallel](../yaml/index.md#parallel) keyword,
giving you powerful options for parallelization within your pipeline. giving you powerful options for parallelization within your pipeline.
## Limitations ## Limitations
...@@ -87,7 +87,7 @@ are certain use cases that you may need to work around. For more information, ch ...@@ -87,7 +87,7 @@ are certain use cases that you may need to work around. For more information, ch
The needs visualization makes it easier to visualize the relationships between dependent jobs in a DAG. This graph displays all the jobs in a pipeline that need or are needed by other jobs. Jobs with no relationships are not displayed in this view. The needs visualization makes it easier to visualize the relationships between dependent jobs in a DAG. This graph displays all the jobs in a pipeline that need or are needed by other jobs. Jobs with no relationships are not displayed in this view.
To see the needs visualization, click on the **Needs** tab when viewing a pipeline that uses the `needs:` keyword. To see the needs visualization, click on the **Needs** tab when viewing a pipeline that uses the `needs` keyword.
![Needs visualization example](img/dag_graph_example_v13_1.png) ![Needs visualization example](img/dag_graph_example_v13_1.png)
......
doc/ci/environments/index.md
View file @ cb512a13
...@@ -294,7 +294,7 @@ As soon as the `review` job finishes, GitLab updates the `review/your-branch-nam ...@@ -294,7 +294,7 @@ As soon as the `review` job finishes, GitLab updates the `review/your-branch-nam
environment's URL. environment's URL.
It parses the `deploy.env` report artifact, registers a list of variables as runtime-created, It parses the `deploy.env` report artifact, registers a list of variables as runtime-created,
uses it for expanding `environment:url: $DYNAMIC_ENVIRONMENT_URL` and sets it to the environment URL. uses it for expanding `environment:url: $DYNAMIC_ENVIRONMENT_URL` and sets it to the environment URL.
You can also specify a static part of the URL at `environment:url:`, such as You can also specify a static part of the URL at `environment:url`, such as
`https://$DYNAMIC_ENVIRONMENT_URL`. If the value of `DYNAMIC_ENVIRONMENT_URL` is `https://$DYNAMIC_ENVIRONMENT_URL`. If the value of `DYNAMIC_ENVIRONMENT_URL` is
`example.com`, the final result is `https://example.com`. `example.com`, the final result is `https://example.com`.
...@@ -303,7 +303,7 @@ The assigned URL for the `review/your-branch-name` environment is visible in the ...@@ -303,7 +303,7 @@ The assigned URL for the `review/your-branch-name` environment is visible in the
Note the following: Note the following:
- `stop_review` doesn't generate a dotenv report artifact, so it doesn't recognize the - `stop_review` doesn't generate a dotenv report artifact, so it doesn't recognize the
`DYNAMIC_ENVIRONMENT_URL` environment variable. Therefore you shouldn't set `environment:url:` in the `DYNAMIC_ENVIRONMENT_URL` environment variable. Therefore you shouldn't set `environment:url` in the
`stop_review` job. `stop_review` job.
- If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update - If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update
the environment URL. the environment URL.
...@@ -451,7 +451,7 @@ Read more in the [`.gitlab-ci.yml` reference](../yaml/index.md#environmenton_sto ...@@ -451,7 +451,7 @@ Read more in the [`.gitlab-ci.yml` reference](../yaml/index.md#environmenton_sto
You can set an environment to stop when another job is finished. You can set an environment to stop when another job is finished.
In your `.gitlab-ci.yml` file, specify in the [`on_stop:`](../yaml/index.md#environmenton_stop) In your `.gitlab-ci.yml` file, specify in the [`on_stop`](../yaml/index.md#environmenton_stop)
keyword the name of the job that stops the environment. keyword the name of the job that stops the environment.
The following example shows a `review_app` job that calls a `stop_review_app` job after the first The following example shows a `review_app` job that calls a `stop_review_app` job after the first
...@@ -478,7 +478,7 @@ The `stop_review_app` job **must** have the following keywords defined: ...@@ -478,7 +478,7 @@ The `stop_review_app` job **must** have the following keywords defined:
- `when`, defined at either: - `when`, defined at either:
- [The job level](../yaml/index.md#when). - [The job level](../yaml/index.md#when).
- [In a rules clause](../yaml/index.md#rules). If you use `rules:` and `when: manual`, you should - [In a rules clause](../yaml/index.md#rules). If you use `rules` and `when: manual`, you should
also set [`allow_failure: true`](../yaml/index.md#allow_failure) so the pipeline can complete also set [`allow_failure: true`](../yaml/index.md#allow_failure) so the pipeline can complete
even if the job doesn't run. even if the job doesn't run.
- `environment:name` - `environment:name`
......
doc/ci/jobs/job_control.md
View file @ cb512a13
...@@ -79,7 +79,7 @@ job: ...@@ -79,7 +79,7 @@ job:
- In **all other cases**, the job is added to the pipeline, with `when: on_success`. - In **all other cases**, the job is added to the pipeline, with `when: on_success`.
WARNING: WARNING:
If you use a `when:` clause as the final rule (not including `when: never`), two If you use a `when` clause as the final rule (not including `when: never`), two
simultaneous pipelines may start. Both push pipelines and merge request pipelines can 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). be triggered by the same event (a push to the source branch for an open merge request).
See how to [prevent duplicate pipelines](#avoid-duplicate-pipelines) See how to [prevent duplicate pipelines](#avoid-duplicate-pipelines)
...@@ -153,7 +153,7 @@ To avoid duplicate pipelines, you can: ...@@ -153,7 +153,7 @@ To avoid duplicate pipelines, you can:
- Use [`workflow`](../yaml/index.md#workflow) to specify which types of pipelines - Use [`workflow`](../yaml/index.md#workflow) to specify which types of pipelines
can run. can run.
- Rewrite the rules to run the job only in very specific cases, - Rewrite the rules to run the job only in very specific cases,
and avoid a final `when:` rule: and avoid a final `when` rule:
```yaml ```yaml
job: job:
...@@ -480,8 +480,8 @@ All files are considered to have changed when a scheduled pipeline runs. ...@@ -480,8 +480,8 @@ All files are considered to have changed when a scheduled pipeline runs.
If you use multiple keywords with `only` or `except`, the keywords are evaluated If you use multiple keywords with `only` or `except`, the keywords are evaluated
as a single conjoined expression. That is: as a single conjoined expression. That is:
- `only:` includes the job if **all** of the keys have at least one condition that matches. - `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. - `except` excludes the job if **any** of the keys have at least one condition that matches.
With `only`, individual keys are logically joined by an `AND`. A job is added to With `only`, individual keys are logically joined by an `AND`. A job is added to
the pipeline if the following is true: the pipeline if the following is true:
......
doc/ci/migration/jenkins.md
View file @ cb512a13
...@@ -146,15 +146,15 @@ as well. ...@@ -146,15 +146,15 @@ as well.
Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code. Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code.
GitLab works a bit differently, we use the more highly structured [YAML](https://yaml.org/) format, which GitLab works a bit differently, we use the more highly structured [YAML](https://yaml.org/) format, which
places scripting elements inside of `script:` blocks separate from the pipeline specification itself. places scripting elements inside of `script` blocks separate from the pipeline specification itself.
This is a strength of GitLab, in that it helps keep the learning curve much simpler to get up and running This is a strength of GitLab, in that it helps keep the learning curve much simpler to get up and running
and avoids some of the problem of unconstrained complexity which can make your Jenkinsfile hard to understand and avoids some of the problem of unconstrained complexity which can make your Jenkinsfile hard to understand
and manage. and manage.
That said, we do of course still value DRY (don't repeat yourself) principles and want to ensure that That said, we do of course still value DRY (don't repeat yourself) principles and want to ensure that
behaviors of your jobs can be codified once and applied as needed. You can use the `extends:` syntax to behaviors of your jobs can be codified once and applied as needed. You can use the `extends` syntax to
[reuse configuration in your jobs](../yaml/index.md#extends), and `include:` can [reuse configuration in your jobs](../yaml/index.md#extends), and `include` can
be used to [reuse pipeline configurations](../yaml/index.md#include) in pipelines be used to [reuse pipeline configurations](../yaml/index.md#include) in pipelines
in different projects: in different projects:
...@@ -174,7 +174,7 @@ rspec: ...@@ -174,7 +174,7 @@ rspec:
## Artifact publishing ## Artifact publishing
Artifacts may work a bit differently than you've used them with Jenkins. In GitLab, any job can define Artifacts may work a bit differently than you've used them with Jenkins. In GitLab, any job can define
a set of artifacts to be saved by using the `artifacts:` keyword. This can be configured to point to a file a set of artifacts to be saved by using the `artifacts` keyword. This can be configured to point to a file
or set of files that can then be persisted from job to job. Read more on our detailed or set of files that can then be persisted from job to job. Read more on our detailed
[artifacts documentation](../pipelines/job_artifacts.md): [artifacts documentation](../pipelines/job_artifacts.md):
...@@ -271,7 +271,7 @@ default: ...@@ -271,7 +271,7 @@ default:
GitLab CI/CD also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/index.md#stages) GitLab CI/CD also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/index.md#stages)
is a top level setting that enumerates the list of stages, but you are not required to nest individual jobs underneath is a top level setting that enumerates the list of stages, but you are not required to nest individual jobs underneath
the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the
[`stage:` keyword](../yaml/index.md#stage). [`stage` keyword](../yaml/index.md#stage).
Note that, unless otherwise specified, every pipeline is instantiated with a `build`, `test`, and `deploy` stage Note that, unless otherwise specified, every pipeline is instantiated with a `build`, `test`, and `deploy` stage
which are run in that order. Jobs that have no `stage` defined are placed by default in the `test` stage. which are run in that order. Jobs that have no `stage` defined are placed by default in the `test` stage.
......
doc/ci/pipelines/merge_request_pipelines.md
View file @ cb512a13
...@@ -112,11 +112,11 @@ C: ...@@ -112,11 +112,11 @@ C:
- merge_requests - merge_requests
``` ```
- `A` and `B` always run, because they get the `only:` rule to execute in all cases. - `A` and `B` always run, because they get the `only` rule to execute in all cases.
- `C` only runs for merge requests. It doesn't run for any pipeline - `C` only runs for merge requests. It doesn't run for any pipeline
except a merge request pipeline. except a merge request pipeline.
In this example, you don't have to add the `only:` rule to all of your jobs to make In this example, you don't have to add the `only` rule to all of your jobs to make
them always run. You can use this format to set up a Review App, which helps to them always run. You can use this format to set up a Review App, which helps to
save resources. save resources.
......
doc/ci/pipelines/multi_project_pipelines.md
View file @ cb512a13
...@@ -213,7 +213,7 @@ In the upstream pipeline: ...@@ -213,7 +213,7 @@ In the upstream pipeline:
``` ```
1. Set the `test` job in the downstream pipeline to inherit the variables from the `build_vars` 1. Set the `test` job in the downstream pipeline to inherit the variables from the `build_vars`
job in the upstream project with `needs:`. The `test` job inherits the variables in the job in the upstream project with `needs`. The `test` job inherits the variables in the
`dotenv` report and it can access `BUILD_VERSION` in the script: `dotenv` report and it can access `BUILD_VERSION` in the script:
```yaml ```yaml
......
doc/ci/pipelines/parent_child_pipelines.md
View file @ cb512a13
...@@ -42,7 +42,7 @@ Child pipelines work well with other GitLab CI/CD features: ...@@ -42,7 +42,7 @@ Child pipelines work well with other GitLab CI/CD features:
- Since the parent pipeline in `.gitlab-ci.yml` and the child pipeline run as normal - Since the parent pipeline in `.gitlab-ci.yml` and the child pipeline run as normal
pipelines, they can have their own behaviors and sequencing in relation to triggers. pipelines, they can have their own behaviors and sequencing in relation to triggers.
See the [`trigger:`](../yaml/index.md#trigger) keyword documentation for full details on how to See the [`trigger`](../yaml/index.md#trigger) keyword documentation for full details on how to
include the child pipeline configuration. include the child pipeline configuration.
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
...@@ -84,7 +84,7 @@ microservice_a: ...@@ -84,7 +84,7 @@ microservice_a:
file: '/path/to/child-pipeline.yml' file: '/path/to/child-pipeline.yml'
``` ```
The maximum number of entries that are accepted for `trigger:include:` is three. The maximum number of entries that are accepted for `trigger:include` is three.
Similar to [multi-project pipelines](multi_project_pipelines.md#mirror-status-of-a-triggered-pipeline-in-the-trigger-job), Similar to [multi-project pipelines](multi_project_pipelines.md#mirror-status-of-a-triggered-pipeline-in-the-trigger-job),
we can set the parent pipeline to depend on the status of the child pipeline upon completion: we can set the parent pipeline to depend on the status of the child pipeline upon completion:
......
doc/ci/pipelines/pipeline_architectures.md
View file @ cb512a13
...@@ -211,7 +211,7 @@ trigger_b: ...@@ -211,7 +211,7 @@ trigger_b:
``` ```
Example child `a` pipeline configuration, located in `/a/.gitlab-ci.yml`, making Example child `a` pipeline configuration, located in `/a/.gitlab-ci.yml`, making
use of the DAG `needs:` keyword: use of the DAG `needs` keyword:
```yaml ```yaml
stages: stages:
...@@ -240,7 +240,7 @@ deploy_a: ...@@ -240,7 +240,7 @@ deploy_a:
``` ```
Example child `b` pipeline configuration, located in `/b/.gitlab-ci.yml`, making Example child `b` pipeline configuration, located in `/b/.gitlab-ci.yml`, making
use of the DAG `needs:` keyword: use of the DAG `needs` keyword:
```yaml ```yaml
stages: stages:
......
doc/ci/pipelines/settings.md
View file @ cb512a13
...@@ -267,7 +267,7 @@ when merging a merge request would cause the project's test coverage to decline. ...@@ -267,7 +267,7 @@ when merging a merge request would cause the project's test coverage to decline.
Follow these steps to enable the `Coverage-Check` MR approval rule: Follow these steps to enable the `Coverage-Check` MR approval rule:
1. Set up a [`coverage:`](../yaml/index.md#coverage) regular expression for all jobs you want to include in the overall coverage value. 1. Set up a [`coverage`](../yaml/index.md#coverage) regular expression for all jobs you want to include in the overall coverage value.
1. Go to your project and select **Settings > General**. 1. Go to your project and select **Settings > General**.
1. Expand **Merge request approvals**. 1. Expand **Merge request approvals**.
1. Select **Enable** next to the `Coverage-Check` approval rule. 1. Select **Enable** next to the `Coverage-Check` approval rule.
......
doc/ci/services/gitlab.md
View file @ cb512a13
...@@ -28,7 +28,7 @@ NOTE: ...@@ -28,7 +28,7 @@ NOTE:
Variables set in the GitLab UI are not passed down to the service containers. Variables set in the GitLab UI are not passed down to the service containers.
[Learn more](../variables/index.md#). [Learn more](../variables/index.md#).
Then, commands in `script:` sections in your `.gitlab-ci.yml` file can access the API at `http://gitlab/api/v4`. Then, commands in `script` sections in your `.gitlab-ci.yml` file can access the API at `http://gitlab/api/v4`.
For more information about why `gitlab` is used for the `Host`, see For more information about why `gitlab` is used for the `Host`, see
[How services are linked to the job](../docker/using_docker_images.md#extended-docker-configuration-options). [How services are linked to the job](../docker/using_docker_images.md#extended-docker-configuration-options).
......
doc/ci/triggers/index.md
View file @ cb512a13
...@@ -23,7 +23,7 @@ depending on which trigger method is used. ...@@ -23,7 +23,7 @@ depending on which trigger method is used.
| `$CI_PIPELINE_SOURCE` value | Trigger method | | `$CI_PIPELINE_SOURCE` value | Trigger method |
|-----------------------------|----------------| |-----------------------------|----------------|
| `pipeline` | Using the `trigger:` keyword in the CI/CD configuration file, or using the trigger API with `$CI_JOB_TOKEN`. | | `pipeline` | Using the `trigger` keyword in the CI/CD configuration file, or using the trigger API with `$CI_JOB_TOKEN`. |
| `trigger` | Using the trigger API using a generated trigger token | | `trigger` | Using the trigger API using a generated trigger token |
This also applies when using the `pipelines` or `triggers` keywords with the legacy [`only/except` basic syntax](../yaml/index.md#only--except). This also applies when using the `pipelines` or `triggers` keywords with the legacy [`only/except` basic syntax](../yaml/index.md#only--except).
......
doc/ci/troubleshooting.md
View file @ cb512a13
...@@ -291,7 +291,7 @@ Pipeline configuration warnings are shown when you: ...@@ -291,7 +291,7 @@ Pipeline configuration warnings are shown when you:
### "Job may allow multiple pipelines to run for a single action" warning ### "Job may allow multiple pipelines to run for a single action" warning
When you use [`rules`](yaml/index.md#rules) with a `when:` clause without an `if:` When you use [`rules`](yaml/index.md#rules) with a `when` clause without an `if`
clause, multiple pipelines may run. Usually this occurs when you push a commit to clause, multiple pipelines may run. Usually this occurs when you push a commit to
a branch that has an open merge request associated with it. a branch that has an open merge request associated with it.
......
doc/ci/yaml/index.md
View file @ cb512a13
...@@ -73,7 +73,7 @@ or import additional pipeline configuration. ...@@ -73,7 +73,7 @@ or import additional pipeline configuration.
### `default` ### `default`
You can set global defaults for some keywords. Jobs that do not define one or more You can set global defaults for some keywords. Jobs that do not define one or more
of the listed keywords use the value defined in the `default:` section. of the listed keywords use the value defined in the `default` section.
**Keyword type**: Global keyword. **Keyword type**: Global keyword.
...@@ -106,7 +106,7 @@ rspec 2.7: ...@@ -106,7 +106,7 @@ rspec 2.7:
In this example, `ruby:3.0` is the default `image` value for all jobs in the pipeline. In this example, `ruby:3.0` is the default `image` value for all jobs in the pipeline.
The `rspec 2.7` job does not use the default, because it overrides the default with The `rspec 2.7` job does not use the default, because it overrides the default with
a job-specific `image:` section: a job-specific `image` section:
**Additional details**: **Additional details**:
...@@ -368,7 +368,7 @@ Use [`workflow`](workflow.md) to control pipeline behavior. ...@@ -368,7 +368,7 @@ Use [`workflow`](workflow.md) to control pipeline behavior.
#### `workflow:rules` #### `workflow:rules`
The `rules` keyword in `workflow` is similar to [`rules:` defined in jobs](#rules), The `rules` keyword in `workflow` is similar to [`rules` defined in jobs](#rules),
but controls whether or not a whole pipeline is created. but controls whether or not a whole pipeline is created.
When no rules evaluate to true, the pipeline does not run. When no rules evaluate to true, the pipeline does not run.
...@@ -414,7 +414,7 @@ and the pipeline is for either: ...@@ -414,7 +414,7 @@ and the pipeline is for either:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294232) in GitLab 13.11. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294232) in GitLab 13.11.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/300997) in GitLab 14.1. > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/300997) in GitLab 14.1.
You can use [`variables`](#variables) in `workflow:rules:` to define variables for You can use [`variables`](#variables) in `workflow:rules` to define variables for
specific pipeline conditions. specific pipeline conditions.
When the condition matches, the variable is created and can be used by all jobs When the condition matches, the variable is created and can be used by all jobs
...@@ -486,7 +486,7 @@ The following topics explain how to use keywords to configure CI/CD pipelines. ...@@ -486,7 +486,7 @@ The following topics explain how to use keywords to configure CI/CD pipelines.
Use `after_script` to define an array of commands that run after each job, including failed jobs. Use `after_script` to define an array of commands that run after each job, including failed jobs.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: An array including: **Possible inputs**: An array including:
...@@ -585,7 +585,7 @@ In this example, `job1` and `job2` run in parallel: ...@@ -585,7 +585,7 @@ In this example, `job1` and `job2` run in parallel:
**Additional details**: **Additional details**:
- You can use `allow_failure` as a subkey of [`rules:`](#rulesallow_failure). - You can use `allow_failure` as a subkey of [`rules`](#rulesallow_failure).
- You can use `allow_failure: false` with a manual job to create a [blocking manual job](../jobs/job_control.md#types-of-manual-jobs). - You can use `allow_failure: false` with a manual job to create a [blocking manual job](../jobs/job_control.md#types-of-manual-jobs).
A blocked pipeline does not run any jobs in later stages until the manual job A blocked pipeline does not run any jobs in later stages until the manual job
is started and completes successfully. is started and completes successfully.
...@@ -656,7 +656,7 @@ artifacts are restored after [caches](#cache). ...@@ -656,7 +656,7 @@ artifacts are restored after [caches](#cache).
Use `artifacts:exclude` to prevent files from being added to an artifacts archive. Use `artifacts:exclude` to prevent files from being added to an artifacts archive.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -709,7 +709,7 @@ After their expiry, artifacts are deleted hourly by default (using a cron job), ...@@ -709,7 +709,7 @@ After their expiry, artifacts are deleted hourly by default (using a cron job),
accessible anymore. accessible anymore.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: The expiry time. If no unit is provided, the time is in seconds. **Possible inputs**: The expiry time. If no unit is provided, the time is in seconds.
Valid values include: Valid values include:
...@@ -749,7 +749,7 @@ Use the `artifacts:expose_as` keyword to ...@@ -749,7 +749,7 @@ Use the `artifacts:expose_as` keyword to
[expose job artifacts in the merge request UI](../pipelines/job_artifacts.md#expose-job-artifacts-in-the-merge-request-ui). [expose job artifacts in the merge request UI](../pipelines/job_artifacts.md#expose-job-artifacts-in-the-merge-request-ui).
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -793,7 +793,7 @@ archive. You can specify a unique name for every archive. ...@@ -793,7 +793,7 @@ archive. You can specify a unique name for every archive.
If not defined, the default name is `artifacts`, which becomes `artifacts.zip` when downloaded. If not defined, the default name is `artifacts`, which becomes `artifacts.zip` when downloaded.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -822,7 +822,7 @@ Paths are relative to the project directory (`$CI_PROJECT_DIR`) and can't direct ...@@ -822,7 +822,7 @@ Paths are relative to the project directory (`$CI_PROJECT_DIR`) and can't direct
link outside it. link outside it.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -872,7 +872,7 @@ To deny read access for anonymous and guest users to artifacts in public ...@@ -872,7 +872,7 @@ To deny read access for anonymous and guest users to artifacts in public
pipelines, set `artifacts:public` to `false`: pipelines, set `artifacts:public` to `false`:
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -892,7 +892,7 @@ Use [`artifacts:reports`](artifacts_reports.md) to collect artifacts generated b ...@@ -892,7 +892,7 @@ Use [`artifacts:reports`](artifacts_reports.md) to collect artifacts generated b
included templates in jobs. included templates in jobs.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: See list of available [artifacts reports types](artifacts_reports.md). **Possible inputs**: See list of available [artifacts reports types](artifacts_reports.md).
...@@ -925,7 +925,7 @@ with the paths defined in `artifacts:paths`). `artifacts:untracked` ignores conf ...@@ -925,7 +925,7 @@ with the paths defined in `artifacts:paths`). `artifacts:untracked` ignores conf
in the repository's `.gitignore` file. in the repository's `.gitignore` file.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -951,7 +951,7 @@ Use `artifacts:when` to upload artifacts on job failure or despite the ...@@ -951,7 +951,7 @@ Use `artifacts:when` to upload artifacts on job failure or despite the
failure. failure.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -975,7 +975,7 @@ Use `before_script` to define an array of commands that should run before each j ...@@ -975,7 +975,7 @@ Use `before_script` to define an array of commands that should run before each j
`script` commands, but after [artifacts](#artifacts) are restored. `script` commands, but after [artifacts](#artifacts) are restored.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: An array including: **Possible inputs**: An array including:
...@@ -1022,7 +1022,7 @@ Learn more about caches in [Caching in GitLab CI/CD](../caching/index.md). ...@@ -1022,7 +1022,7 @@ Learn more about caches in [Caching in GitLab CI/CD](../caching/index.md).
Use the `cache:paths` keyword to choose which files or directories to cache. Use the `cache:paths` keyword to choose which files or directories to cache.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: An array of paths relative to the project directory (`$CI_PROJECT_DIR`). **Possible inputs**: An array of paths relative to the project directory (`$CI_PROJECT_DIR`).
You can use wildcards that use [glob](https://en.wikipedia.org/wiki/Glob_(programming)) You can use wildcards that use [glob](https://en.wikipedia.org/wiki/Glob_(programming))
...@@ -1058,11 +1058,11 @@ rspec: ...@@ -1058,11 +1058,11 @@ rspec:
Use the `cache:key` keyword to give each cache a unique identifying key. All jobs Use the `cache:key` keyword to give each cache a unique identifying key. All jobs
that use the same cache key use the same cache, including in different pipelines. that use the same cache key use the same cache, including in different pipelines.
If not set, the default key is `default`. All jobs with the `cache:` keyword but If not set, the default key is `default`. All jobs with the `cache` keyword but
no `cache:key` share the `default` cache. no `cache:key` share the `default` cache.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -1112,7 +1112,7 @@ change. `cache:key:files` lets you reuse some caches, and rebuild them less ofte ...@@ -1112,7 +1112,7 @@ change. `cache:key:files` lets you reuse some caches, and rebuild them less ofte
which speeds up subsequent pipeline runs. which speeds up subsequent pipeline runs.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: An array of one or two file paths. **Possible inputs**: An array of one or two file paths.
...@@ -1151,7 +1151,7 @@ that changed each listed file. ...@@ -1151,7 +1151,7 @@ that changed each listed file.
Use `cache:key:prefix` to combine a prefix with the SHA computed for [`cache:key:files`](#cachekeyfiles). Use `cache:key:prefix` to combine a prefix with the SHA computed for [`cache:key:files`](#cachekeyfiles).
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -1188,7 +1188,7 @@ is not found, the prefix is added to `default`, so the key in the example would ...@@ -1188,7 +1188,7 @@ is not found, the prefix is added to `default`, so the key in the example would
Use `untracked: true` to cache all files that are untracked in your Git repository: Use `untracked: true` to cache all files that are untracked in your Git repository:
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: `true` or `false` (default). **Possible inputs**: `true` or `false` (default).
...@@ -1222,7 +1222,7 @@ rspec: ...@@ -1222,7 +1222,7 @@ rspec:
Use `cache:when` to define when to save the cache, based on the status of the job. Use `cache:when` to define when to save the cache, based on the status of the job.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -1260,7 +1260,7 @@ This policy speeds up job execution and reduces load on the cache server. You ca ...@@ -1260,7 +1260,7 @@ This policy speeds up job execution and reduces load on the cache server. You ca
use a job with the `push` policy to build the cache. use a job with the `push` policy to build the cache.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -1359,7 +1359,7 @@ dast: ...@@ -1359,7 +1359,7 @@ dast:
scanner_profile: "Quick Passive Test" scanner_profile: "Quick Passive Test"
``` ```
In this example, the `dast` job extends the `dast` configuration added with the `include:` keyword In this example, the `dast` job extends the `dast` configuration added with the `include` keyword
to select a specific site profile and scanner profile. to select a specific site profile and scanner profile.
**Additional details**: **Additional details**:
...@@ -1746,7 +1746,7 @@ rspec: ...@@ -1746,7 +1746,7 @@ rspec:
Use `image` to specify a Docker image that the job runs in. Use `image` to specify a Docker image that the job runs in.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: The name of the image, including the registry path if needed, in one of these formats: **Possible inputs**: The name of the image, including the registry path if needed, in one of these formats:
...@@ -1770,7 +1770,7 @@ rspec 2.7: ...@@ -1770,7 +1770,7 @@ rspec 2.7:
In this example, the `ruby:3.0` image is the default for all jobs in the pipeline. In this example, the `ruby:3.0` image is the default for all jobs in the pipeline.
The `rspec 2.7` job does not use the default, because it overrides the default with The `rspec 2.7` job does not use the default, because it overrides the default with
a job-specific `image:` section. a job-specific `image` section.
**Related topics**: **Related topics**:
...@@ -1778,10 +1778,10 @@ a job-specific `image:` section. ...@@ -1778,10 +1778,10 @@ a job-specific `image:` section.
#### `image:name` #### `image:name`
The name of the Docker image that the job runs in. Similar to [`image:`](#image) used by itself. The name of the Docker image that the job runs in. Similar to [`image`](#image) used by itself.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: The name of the image, including the registry path if needed, in one of these formats: **Possible inputs**: The name of the image, including the registry path if needed, in one of these formats:
...@@ -1809,7 +1809,7 @@ The syntax is similar to the [Dockerfile `ENTRYPOINT` directive](https://docs.do ...@@ -1809,7 +1809,7 @@ The syntax is similar to the [Dockerfile `ENTRYPOINT` directive](https://docs.do
where each shell token is a separate string in the array. where each shell token is a separate string in the array.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: A string. **Possible inputs**: A string.
...@@ -1829,7 +1829,7 @@ image: ...@@ -1829,7 +1829,7 @@ image:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207484) in GitLab 12.9. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207484) in GitLab 12.9.
Use `inherit:` to [control inheritance of globally-defined defaults and variables](../jobs/index.md#control-the-inheritance-of-default-keywords-and-global-variables). Use `inherit` to [control inheritance of globally-defined defaults and variables](../jobs/index.md#control-the-inheritance-of-default-keywords-and-global-variables).
#### `inherit:default` #### `inherit:default`
...@@ -1916,7 +1916,7 @@ a new pipeline starts on the same branch. ...@@ -1916,7 +1916,7 @@ a new pipeline starts on the same branch.
You can't cancel subsequent jobs after a job with `interruptible: false` starts. You can't cancel subsequent jobs after a job with `interruptible: false` starts.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: `true` or `false` (default). **Possible inputs**: `true` or `false` (default).
...@@ -1965,7 +1965,7 @@ In this example, a new pipeline causes a running pipeline to be: ...@@ -1965,7 +1965,7 @@ In this example, a new pipeline causes a running pipeline to be:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30631) in GitLab 12.8, `needs: []` lets jobs start immediately. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30631) in GitLab 12.8, `needs: []` lets jobs start immediately.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30632) in GitLab 14.2, you can refer to jobs in the same stage as the job you are configuring. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30632) in GitLab 14.2, you can refer to jobs in the same stage as the job you are configuring.
Use `needs:` to execute jobs out-of-order. Relationships between jobs Use `needs` 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). that use `needs` can be visualized as a [directed acyclic graph](../directed_acyclic_graph/index.md).
You can ignore stage ordering and run some jobs without waiting for others to complete. You can ignore stage ordering and run some jobs without waiting for others to complete.
...@@ -2022,11 +2022,11 @@ This example creates four paths of execution: ...@@ -2022,11 +2022,11 @@ This example creates four paths of execution:
**Additional details**: **Additional details**:
- The maximum number of jobs that a single job can have in the `needs:` array is limited: - The maximum number of jobs that a single job can have in the `needs` array is limited:
- For GitLab.com, the limit is 50. For more information, see our - For GitLab.com, the limit is 50. For more information, see our
[infrastructure issue](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/7541). [infrastructure issue](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/7541).
- For self-managed instances, the default limit is 50. This limit [can be changed](../../administration/cicd.md#set-the-needs-job-limit). - For self-managed instances, the default limit is 50. This limit [can be changed](../../administration/cicd.md#set-the-needs-job-limit).
- If `needs:` refers to a job that uses the [`parallel`](#parallel) keyword, - If `needs` refers to a job that uses the [`parallel`](#parallel) keyword,
it depends on all jobs created in parallel, not just one job. It also downloads it depends on all jobs created in parallel, not just one job. It also downloads
artifacts from all the parallel jobs by default. If the artifacts have the same artifacts from all the parallel jobs by default. If the artifacts have the same
name, they overwrite each other and only the last one downloaded is saved. name, they overwrite each other and only the last one downloaded is saved.
...@@ -2035,9 +2035,9 @@ This example creates four paths of execution: ...@@ -2035,9 +2035,9 @@ This example creates four paths of execution:
enabled on GitLab.com and ready for production use. On self-managed [GitLab 14.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/30632) enabled on GitLab.com and ready for production use. On self-managed [GitLab 14.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/30632)
this feature is available by default. this feature is available by default.
- In GitLab 14.0 and older, you can only refer to jobs in earlier stages. Stages must be - In GitLab 14.0 and older, you can only refer to jobs in earlier stages. Stages must be
explicitly defined for all jobs that use the `needs:` keyword, or are referenced explicitly defined for all jobs that use the `needs` keyword, or are referenced
in a job's `needs:` section. in a job's `needs` section.
- In GitLab 13.9 and older, if `needs:` refers to a job that might not be added to - In GitLab 13.9 and older, if `needs` refers to a job that might not be added to
a pipeline because of `only`, `except`, or `rules`, the pipeline might fail to create. a pipeline because of `only`, `except`, or `rules`, the pipeline might fail to create.
#### `needs:artifacts` #### `needs:artifacts`
...@@ -2046,7 +2046,7 @@ This example creates four paths of execution: ...@@ -2046,7 +2046,7 @@ This example creates four paths of execution:
When a job uses `needs`, it no longer downloads all artifacts from previous stages When a job uses `needs`, it no longer downloads all artifacts from previous stages
by default, because jobs with `needs` can start before earlier stages complete. With by default, because jobs with `needs` can start before earlier stages complete. With
`needs` you can only download artifacts from the jobs listed in the `needs:` configuration. `needs` you can only download artifacts from the jobs listed in the `needs` configuration.
Use `artifacts: true` (default) or `artifacts: false` to control when artifacts are Use `artifacts: true` (default) or `artifacts: false` to control when artifacts are
downloaded in jobs that use `needs`. downloaded in jobs that use `needs`.
...@@ -2085,7 +2085,7 @@ In this example: ...@@ -2085,7 +2085,7 @@ In this example:
- The `test-job1` job downloads the `build_job1` artifacts - The `test-job1` job downloads the `build_job1` artifacts
- The `test-job2` job does not download the `build_job2` artifacts. - The `test-job2` job does not download the `build_job2` artifacts.
- The `test-job3` job downloads the artifacts from all three `build_jobs`, because - The `test-job3` job downloads the artifacts from all three `build_jobs`, because
`artifacts:` is `true`, or defaults to `true`, for all three needed jobs. `artifacts` is `true`, or defaults to `true`, for all three needed jobs.
**Additional details**: **Additional details**:
...@@ -2103,14 +2103,14 @@ If there is a pipeline running for the specified ref, a job with `needs:project` ...@@ -2103,14 +2103,14 @@ If there is a pipeline running for the specified ref, a job with `needs:project`
does not wait for the pipeline to complete. Instead, the job downloads the artifact does not wait for the pipeline to complete. Instead, the job downloads the artifact
from the latest pipeline that completed successfully. from the latest pipeline that completed successfully.
`needs:project` must be used with `job:`, `ref:`, and `artifacts:`. `needs:project` must be used with `job`, `ref`, and `artifacts`.
**Keyword type**: Job keyword. You can use it only as part of a job. **Keyword type**: Job keyword. You can use it only as part of a job.
**Possible inputs**: **Possible inputs**:
- `needs:project`: A full project path, including namespace and group. If the - `needs:project`: A full project path, including namespace and group. If the
project is in the same group or namespace, you can omit them from the `project:` project is in the same group or namespace, you can omit them from the `project`
keyword. For example: `project: group/project-name` or `project: project-name`. keyword. For example: `project: group/project-name` or `project: project-name`.
- `job`: The job to download artifacts from. - `job`: The job to download artifacts from.
- `ref`: The ref to download artifacts from. - `ref`: The ref to download artifacts from.
...@@ -2150,7 +2150,7 @@ build_job: ...@@ -2150,7 +2150,7 @@ build_job:
**Additional details**: **Additional details**:
- To download artifacts from a different pipeline in the current project, set `project:` - To download artifacts from a different pipeline in the current project, set `project`
to be the same as the current project, but use a different ref than the current pipeline. to be the same as the current project, but use a different ref than the current pipeline.
Concurrent pipelines running on the same ref could override the artifacts. Concurrent pipelines running on the same ref could override the artifacts.
- The user running the pipeline must have at least the Reporter role for the group or project, - The user running the pipeline must have at least the Reporter role for the group or project,
...@@ -2160,7 +2160,7 @@ build_job: ...@@ -2160,7 +2160,7 @@ build_job:
the needed job to complete. [Directed acyclic graph](../directed_acyclic_graph/index.md) the needed job to complete. [Directed acyclic graph](../directed_acyclic_graph/index.md)
behavior is limited to jobs in the same pipeline. Make sure that the needed job in the other behavior is limited to jobs in the same pipeline. Make sure that the needed job in the other
pipeline completes before the job that needs it tries to download the artifacts. pipeline completes before the job that needs it tries to download the artifacts.
- You can't download artifacts from jobs that run in [`parallel:`](#parallel). - You can't download artifacts from jobs that run in [`parallel`](#parallel).
- Support for [CI/CD variables](../variables/index.md) in `project`, `job`, and `ref` was - Support for [CI/CD variables](../variables/index.md) in `project`, `job`, and `ref` was
[introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202093) in GitLab 13.3. [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202093) in GitLab 13.3.
[Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/235761) in GitLab 13.4. [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/235761) in GitLab 13.4.
...@@ -2182,7 +2182,7 @@ its parent pipeline or another child pipeline in the same parent-child pipeline ...@@ -2182,7 +2182,7 @@ its parent pipeline or another child pipeline in the same parent-child pipeline
**Possible inputs**: **Possible inputs**:
- `needs:pipeline`: A pipeline ID. Must be a pipeline present in the same parent-child pipeline hierarchy. - `needs:pipeline`: A pipeline ID. Must be a pipeline present in the same parent-child pipeline hierarchy.
- `job:`: The job to download artifacts from. - `job`: The job to download artifacts from.
**Example of `needs:pipeline:job`**: **Example of `needs:pipeline:job`**:
...@@ -2244,7 +2244,7 @@ error similar to: ...@@ -2244,7 +2244,7 @@ error similar to:
**Possible inputs**: **Possible inputs**:
- `job:`: The job to make optional. - `job`: The job to make optional.
- `true` or `false` (default). - `true` or `false` (default).
**Example of `needs:optional`**: **Example of `needs:optional`**:
...@@ -2281,7 +2281,7 @@ replicated to the bridge job. ...@@ -2281,7 +2281,7 @@ replicated to the bridge job.
**Possible inputs**: **Possible inputs**:
- A full project path, including namespace and group. If the - A full project path, including namespace and group. If the
project is in the same group or namespace, you can omit them from the `project:` project is in the same group or namespace, you can omit them from the `project`
keyword. For example: `project: group/project-name` or `project: project-name`. keyword. For example: `project: group/project-name` or `project: project-name`.
**Example of `needs:pipeline`**: **Example of `needs:pipeline`**:
...@@ -2636,7 +2636,7 @@ you can use this image from the GitLab Container Registry: `registry.gitlab.com/ ...@@ -2636,7 +2636,7 @@ you can use this image from the GitLab Container Registry: `registry.gitlab.com/
**Keyword type**: Job keyword. You can use it only as part of a job. **Keyword type**: Job keyword. You can use it only as part of a job.
**Possible inputs**: The `release:` subkeys: **Possible inputs**: The `release` subkeys:
- [`tag_name`](#releasetag_name) - [`tag_name`](#releasetag_name)
- [`name`](#releasename) (optional) - [`name`](#releasename) (optional)
...@@ -2873,7 +2873,7 @@ By default, all failure types cause the job to be retried. Use [`retry:when`](#r ...@@ -2873,7 +2873,7 @@ By default, all failure types cause the job to be retried. Use [`retry:when`](#r
to select which failures to retry on. to select which failures to retry on.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: `0` (default), `1`, or `2`. **Possible inputs**: `0` (default), `1`, or `2`.
...@@ -2892,7 +2892,7 @@ Use `retry:when` with `retry:max` to retry jobs for only specific failure cases. ...@@ -2892,7 +2892,7 @@ Use `retry:when` with `retry:max` to retry jobs for only specific failure cases.
`0`, `1`, or `2`. `0`, `1`, or `2`.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: A single failure type, or an array of one or more failure types: **Possible inputs**: A single failure type, or an array of one or more failure types:
...@@ -2996,7 +2996,7 @@ Use `rules:if` clauses to specify when to add a job to a pipeline: ...@@ -2996,7 +2996,7 @@ Use `rules:if` clauses to specify when to add a job to a pipeline:
- If an `if` statement is true, but it's combined with `when: never`, do not add the job to the pipeline. - If an `if` statement is true, but it's combined with `when: never`, do not add the job to the pipeline.
- If no `if` statements are true, do not add the job to the pipeline. - If no `if` statements are true, do not add the job to the pipeline.
`if:` clauses are evaluated based on the values of [predefined CI/CD variables](../variables/predefined_variables.md) `if` clauses are evaluated based on the values of [predefined CI/CD variables](../variables/predefined_variables.md)
or [custom CI/CD variables](../variables/index.md#custom-cicd-variables). or [custom CI/CD variables](../variables/index.md#custom-cicd-variables).
**Keyword type**: Job-specific and pipeline-specific. You can use it as part of a job **Keyword type**: Job-specific and pipeline-specific. You can use it as part of a job
...@@ -3043,7 +3043,7 @@ You should use `rules: changes` only with **branch pipelines** or **merge reques ...@@ -3043,7 +3043,7 @@ You should use `rules: changes` only with **branch pipelines** or **merge reques
You can use `rules: changes` with other pipeline types, but `rules: changes` always You can use `rules: changes` with other pipeline types, but `rules: changes` always
evaluates to true when there is no Git `push` event. Tag pipelines, scheduled pipelines, 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 and so on do **not** have a Git `push` event associated with them. A `rules: changes` job
is **always** added to those pipelines if there is no `if:` that limits the job to is **always** added to those pipelines if there is no `if` that limits the job to
branch or merge request pipelines. branch or merge request pipelines.
**Keyword type**: Job keyword. You can use it only as part of a job. **Keyword type**: Job keyword. You can use it only as part of a job.
...@@ -3112,7 +3112,7 @@ job: ...@@ -3112,7 +3112,7 @@ job:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30235) in GitLab 12.8. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30235) in GitLab 12.8.
Use [`allow_failure: true`](#allow_failure) in `rules:` to allow a job to fail Use [`allow_failure: true`](#allow_failure) in `rules` to allow a job to fail
without stopping the pipeline. without stopping the pipeline.
You can also use `allow_failure: true` with a manual job. The pipeline continues You can also use `allow_failure: true` with a manual job. The pipeline continues
...@@ -3147,7 +3147,7 @@ If the rule matches, then the job is a manual job with `allow_failure: true`. ...@@ -3147,7 +3147,7 @@ If the rule matches, then the job is a manual job with `allow_failure: true`.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209864) in GitLab 13.7. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209864) in GitLab 13.7.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/289803) in GitLab 13.10. > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/289803) in GitLab 13.10.
Use [`variables`](#variables) in `rules:` to define variables for specific conditions. Use [`variables`](#variables) in `rules` to define variables for specific conditions.
**Keyword type**: Job-specific. You can use it only as part of a job. **Keyword type**: Job-specific. You can use it only as part of a job.
...@@ -3309,7 +3309,7 @@ Use `services` to specify an additional Docker image to run scripts in. The [`se ...@@ -3309,7 +3309,7 @@ Use `services` to specify an additional Docker image to run scripts in. The [`se
to the image specified in the [`image`](#image) keyword. to the image specified in the [`image`](#image) keyword.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: The name of the services image, including the registry path if needed, in one of these formats: **Possible inputs**: The name of the services image, including the registry path if needed, in one of these formats:
...@@ -3482,7 +3482,7 @@ example `ruby`, `postgres`, or `development`. To pick up and run a job, a runner ...@@ -3482,7 +3482,7 @@ example `ruby`, `postgres`, or `development`. To pick up and run a job, a runner
be assigned every tag listed in the job. be assigned every tag listed in the job.
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: **Possible inputs**:
...@@ -3520,7 +3520,7 @@ The job-level timeout can be longer than the [project-level timeout](../pipeline ...@@ -3520,7 +3520,7 @@ The job-level timeout can be longer than the [project-level timeout](../pipeline
but can't be longer than the [runner's timeout](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner). but can't be longer than the [runner's timeout](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
**Keyword type**: Job keyword. You can use it only as part of a job or in the **Keyword type**: Job keyword. You can use it only as part of a job or in the
[`default:` section](#default). [`default` section](#default).
**Possible inputs**: A period of time written in natural language. For example, these are all equivalent: **Possible inputs**: A period of time written in natural language. For example, these are all equivalent:
...@@ -3793,7 +3793,7 @@ Defining `image`, `services`, `cache`, `before_script`, and ...@@ -3793,7 +3793,7 @@ Defining `image`, `services`, `cache`, `before_script`, and
`after_script` globally is deprecated. Support could be removed `after_script` globally is deprecated. Support could be removed
from a future release. from a future release.
Use [`default:`](#default) instead. For example: Use [`default`](#default) instead. For example:
```yaml ```yaml
default: default:
......
doc/ci/yaml/script.md
View file @ cb512a13
...@@ -13,7 +13,7 @@ You can use special syntax in [`script`](index.md#script) sections to: ...@@ -13,7 +13,7 @@ You can use special syntax in [`script`](index.md#script) sections to:
- [Create custom collapsible sections](../jobs/index.md#custom-collapsible-sections) - [Create custom collapsible sections](../jobs/index.md#custom-collapsible-sections)
to simplify job log output. to simplify job log output.
## Use special characters with `script:` ## Use special characters with `script`
Sometimes, `script` commands must be wrapped in single or double quotes. Sometimes, `script` commands must be wrapped in single or double quotes.
For example, commands that contain a colon (`:`) must be wrapped in single quotes (`'`). For example, commands that contain a colon (`:`) must be wrapped in single quotes (`'`).
...@@ -101,7 +101,7 @@ WARNING: ...@@ -101,7 +101,7 @@ WARNING:
If multiple commands are combined into one command string, only the last command's If multiple commands are combined into one command string, only the last command's
failure or success is reported. failure or success is reported.
[Failures from earlier commands are ignored due to a bug](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25394). [Failures from earlier commands are ignored due to a bug](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25394).
To work around this, run each command as a separate `script:` item, or add an `exit 1` To work around this, run each command as a separate `script` item, or add an `exit 1`
command to each command string. command to each command string.
You can use the `|` (literal) YAML multiline block scalar indicator to write You can use the `|` (literal) YAML multiline block scalar indicator to write
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7