Skip to content

G
gitlab-ce
Commit 97d96efa authored by Suzanne Selhorn's avatar Suzanne Selhorn
Browse files
Options

Merge branch 'docs-yaml-parameters-to-keywords' into 'master' 

Use keyword and not parameter in CI docs

See merge request gitlab-org/gitlab!45499
parents a2cd7c71 bbc7f66d
Hide whitespace changes
Inline Side-by-side
Showing with 40 additions and 40 deletions
doc/ci/environments/index.md
View file @ 97d96efa
......@@ -304,7 +304,7 @@ Dynamic environments are a fundamental part of [Review apps](../review_apps/inde
#### Allowed variables
The `name` and `url` parameters for dynamic environments can use most available CI/CD variables,
The `name` and `url` keywords for dynamic environments can use most available CI/CD variables,
including:
- [Predefined environment variables](../variables/README.md#predefined-environment-variables)
......
doc/ci/merge_request_pipelines/index.md
View file @ 97d96efa
......@@ -56,7 +56,7 @@ below.
When you use this method, you have to specify `only: - merge_requests` for each job. In this
example, the pipeline contains a `test` job that is configured to run on merge requests.
The `build` and `deploy` jobs don't have the `only: - merge_requests` parameter,
The `build` and `deploy` jobs don't have the `only: - merge_requests` keyword,
so they will not run on merge requests.
```yaml
......@@ -81,8 +81,8 @@ deploy:
#### Excluding certain jobs
The behavior of the `only: [merge_requests]` parameter is such that _only_ jobs with
that parameter are run in the context of a merge request; no other jobs will be run.
The behavior of the `only: [merge_requests]` keyword is such that _only_ jobs with
that keyword are run in the context of a merge request; no other jobs will be run.
However, you can invert this behavior and have all of your jobs run _except_
for one or two.
......
doc/ci/migration/circleci.md
View file @ 97d96efa
......@@ -27,7 +27,7 @@ CircleCI's `config.yml` configuration file defines scripts, jobs, and workflows
### Jobs
In CircleCI, jobs are a collection of steps to perform a specific task. In GitLab, [jobs](../yaml/README.md#introduction) are also a fundamental element in the configuration file. The `checkout` parameter is not necessary in GitLab CI/CD as the repository is automatically fetched.
In CircleCI, jobs are a collection of steps to perform a specific task. In GitLab, [jobs](../yaml/README.md#introduction) are also a fundamental element in the configuration file. The `checkout` keyword is not necessary in GitLab CI/CD as the repository is automatically fetched.
CircleCI example job definition:
......
doc/ci/pipelines/index.md
View file @ 97d96efa
......@@ -157,7 +157,7 @@ For each `var` or `file_var`, a key and value are required.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7931) in GitLab 8.15.
Manual actions, configured using the [`when:manual`](../yaml/README.md#whenmanual) parameter,
Manual actions, configured using the [`when:manual`](../yaml/README.md#whenmanual) keyword,
allow you to require manual interaction before moving forward in the pipeline.
You can do this straight from the pipeline graph. Just click the play button
......@@ -394,7 +394,7 @@ for a single run of the manual job.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21767) in GitLab 11.4.
When you do not want to run a job immediately, you can use the [`when:delayed`](../yaml/README.md#whendelayed) parameter to
When you do not want to run a job immediately, you can use the [`when:delayed`](../yaml/README.md#whendelayed) keyword to
delay a job's execution for a certain period.
This is especially useful for timed incremental rollout where new code is rolled out gradually.
......
doc/ci/pipelines/job_artifacts.md
View file @ 97d96efa
......@@ -44,7 +44,7 @@ are relative to the repository that was cloned during the build.
By default, the artifacts upload when the job succeeds. You can also set artifacts to upload
when the job fails, or always, by using [`artifacts:when`](../yaml/README.md#artifactswhen)
parameter. GitLab keeps these uploaded artifacts for 1 week, as defined
keyword. GitLab keeps these uploaded artifacts for 1 week, as defined
by the `expire_in` definition. You can keep the artifacts from expiring
via the [web interface](#browsing-artifacts). If the expiry time is not defined, it defaults
to the [instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration).
......
doc/ci/yaml/README.md
View file @ 97d96efa
......@@ -93,11 +93,11 @@ If you get validation error when using specific values (for example, `true` or `
- Quote them.
- Change them to a different form. For example, `/bin/true`.
## Configuration parameters
## Job keywords
A job is defined as a list of parameters that define the job's behavior.
A job is defined as a list of keywords that define the job's behavior.
The following table lists available parameters for jobs:
The following table lists available keywords for jobs:
| Keyword | Description |
|:---------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
......@@ -130,17 +130,17 @@ The following table lists available parameters for jobs:
| [`variables`](#variables) | Define job variables on a job level. |
| [`when`](#when) | When to run job. Also available: `when:manual` and `when:delayed`. |
## Global parameters
## Global keywords
Some parameters must be defined at a global level, affecting all jobs in the pipeline.
Some keywords must be defined at a global level, affecting all jobs in the pipeline.
### Global defaults
Some parameters can be set globally as the default for all jobs using the
`default:` keyword. Default parameters can then be overridden by job-specific
Some keywords can be set globally as the default for all jobs using the
`default:` keyword. Default keywords can then be overridden by job-specific
configuration.
The following job parameters can be defined inside a `default:` block:
The following job keywords can be defined inside a `default:` block:
- [`image`](#image)
- [`services`](#services)
......@@ -173,20 +173,20 @@ rspec 2.6:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207484) in GitLab 12.9.
You can disable inheritance of globally defined defaults
and variables with the `inherit:` parameter.
and variables with the `inherit:` keyword.
To enable or disable the inheritance of all `variables:` or `default:` parameters, use the following format:
To enable or disable the inheritance of all `variables:` or `default:` keywords, use the following format:
- `default: true` or `default: false`
- `variables: true` or `variables: false`
To inherit only a subset of `default:` parameters or `variables:`, specify what
To inherit only a subset of `default:` keywords or `variables:`, specify what
you wish to inherit. Anything not listed is **not** inherited. Use
one of the following formats:
```yaml
inherit:
default: [parameter1, parameter2]
default: [keyword1, keyword2]
variables: [VARIABLE1, VARIABLE2]
```
......@@ -195,8 +195,8 @@ Or:
```yaml
inherit:
default:
- parameter1
- parameter2
- keyword1
- keyword2
variables:
- VARIABLE1
- VARIABLE2
......@@ -405,7 +405,7 @@ of using YAML anchors, you can use the [`extends` keyword](#extends).
`include` supports the following inclusion methods:
| Method | Description |
| Keyword | Method |
|:--------------------------------|:------------------------------------------------------------------|
| [`local`](#includelocal) | Include a file from the local project repository. |
| [`file`](#includefile) | Include a file from a different project repository. |
......@@ -548,9 +548,9 @@ for resolving all files is 30 seconds.
There is a list of [additional `includes` examples](includes.md) available.
## Parameter details
## Keyword details
The following are detailed explanations for parameters used to configure CI/CD pipelines.
The following are detailed explanations for keywords used to configure CI/CD pipelines.
### `image`
......@@ -619,7 +619,7 @@ job:
[YAML anchors for scripts](#yaml-anchors-for-script) are available.
This parameter can also contain several commands using an array:
This keyword can also contain several commands using an array:
```yaml
job:
......@@ -1567,7 +1567,7 @@ The [`rules`](#rules) syntax is an improved, more powerful solution for defining
when jobs should run or not. Consider using `rules` instead of `only/except` to get
the most out of your pipelines.
`only` and `except` are two parameters that set a job policy to limit when
`only` and `except` are two keywords that set a job policy to limit when
jobs are created:
1. `only` defines the names of branches and tags the job runs for.
......@@ -1695,7 +1695,7 @@ while just `/issue/` would also match a branch called `severe-issues`.
#### Supported `only`/`except` regexp syntax
In GitLab 11.9.4, GitLab began internally converting the regexp used
in `only` and `except` parameters to [RE2](https://github.com/google/re2/wiki/Syntax).
in `only` and `except` keywords to [RE2](https://github.com/google/re2/wiki/Syntax).
[RE2](https://github.com/google/re2/wiki/Syntax) limits the set of available features
due to computational complexity, and some features, like negative lookaheads, became unavailable.
......@@ -2489,7 +2489,7 @@ deployment to the `production` environment.
> - Before GitLab 8.11, the name of an environment could be defined as a string like
> `environment: production`. The recommended way now is to define it under the
> `name` keyword.
> - The `name` parameter can use any of the defined CI variables,
> - The `name` keyword can use any of the defined CI variables,
> including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
> You however can't use variables defined under `script`.
......@@ -2525,7 +2525,7 @@ deploy to production:
> - Introduced in GitLab 8.11.
> - Before GitLab 8.11, the URL could be added only in GitLab's UI. The
> recommended way now is to define it in `.gitlab-ci.yml`.
> - The `url` parameter can use any of the defined CI variables,
> - The `url` keyword can use any of the defined CI variables,
> including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
> You however can't use variables defined under `script`.
......@@ -2679,7 +2679,7 @@ To follow progress on support for GitLab-managed clusters, see the
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21971) in GitLab 8.12 and GitLab Runner 1.6.
> - The `$CI_ENVIRONMENT_SLUG` was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/22864) in GitLab 8.15.
> - The `name` and `url` parameters can use any of the defined CI variables,
> - The `name` and `url` keywords can use any of the defined CI variables,
> including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
> You however can't use variables defined under `script`.
......@@ -2778,7 +2778,7 @@ The cache is shared between jobs, so if you're using different
paths for different jobs, you should also set a different `cache:key`.
Otherwise cache content can be overwritten.
The `key` parameter defines the affinity of caching between jobs.
The `key` keyword defines the affinity of caching between jobs.
You can have a single cache for all jobs, cache per-job, cache per-branch,
or any other way that fits your workflow. This way, you can fine tune caching,
including caching data between different jobs or even different branches.
......@@ -2847,7 +2847,7 @@ use the new cache, instead of rebuilding the dependencies.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18986) in GitLab v12.5.
When you want to combine a prefix with the SHA computed for `cache:key:files`,
use the `prefix` parameter with `key:files`.
use the `prefix` keyword with `key:files`.
For example, if you add a `prefix` of `test`, the resulting key is: `test-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`.
If neither file was changed in any commits, the prefix is added to `default`, so the
key in the example would be `test-default`.
......@@ -3307,7 +3307,7 @@ It also exposes these reports in GitLab's UI (merge requests, pipeline views, an
These are the available report types:
| Parameter | Description |
| Keyword | Description |
|--------------------------------------------------------------------------------------------------------------------------------------|-------------|
| [`artifacts:reports:cobertura`](../pipelines/job_artifacts.md#artifactsreportscobertura) | The `cobertura` report collects Cobertura coverage XML files. |
| [`artifacts:reports:codequality`](../pipelines/job_artifacts.md#artifactsreportscodequality) | The `codequality` report collects CodeQuality issues. |
......@@ -3329,7 +3329,7 @@ These are the available report types:
> Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
By default, all [`artifacts`](#artifacts) from previous [stages](#stages)
are passed to each job. However, you can use the `dependencies` parameter to
are passed to each job. However, you can use the `dependencies` keyword to
define a limited list of jobs to fetch artifacts from. You can also set a job to download no artifacts at all.
To use this feature, define `dependencies` in context of the job and pass
......@@ -3784,7 +3784,7 @@ starting, which reduces parallelization.
To force a rebuild of a specific branch, tag, or commit, you can use an API call
with a trigger token.
The trigger token is different than the [`trigger`](#trigger) parameter.
The trigger token is different than the [`trigger`](#trigger) keyword.
[Read more in the triggers documentation.](../triggers/README.md)
......@@ -4573,7 +4573,7 @@ feature. Anchors are only valid within the file they were defined in. Instead
of using YAML anchors, you can use the [`extends` keyword](#extends).
The following example uses anchors and map merging. It creates two jobs,
`test1` and `test2`, that inherit the parameters of `.job_template`, each
`test1` and `test2`, that inherit the `.job_template` configuration, each
with their own custom `script` defined:
```yaml
......@@ -4809,9 +4809,9 @@ This limitation does not affect any of the updated merge request pipelines.
All updated merge requests have a pipeline created when using
[pipelines for merge requests](../merge_request_pipelines/index.md).
## Deprecated parameters
## Deprecated keywords
The following parameters are deprecated.
The following keywords are deprecated.
### Globally-defined `types`
......
doc/development/pipelines.md
View file @ 97d96efa
......@@ -618,7 +618,7 @@ each pipeline includes default variables defined in
Most of the jobs [extend from a few CI definitions](../ci/yaml/README.md#extends)
defined in [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/ci/global.gitlab-ci.yml)
that are scoped to a single [configuration parameter](../ci/yaml/README.md#configuration-parameters).
that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-keywords).
| Job definitions | Description |
|------------------|-------------|
......
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