Commit 89ad9d55 authored by Suzanne Selhorn's avatar Suzanne Selhorn Committed by Marcel Amirault

Docs: Fixed Vale CI YAML issues

Closes: https://gitlab.com/gitlab-org/gitlab/-/issues/234029
parent c3ac137b
...@@ -374,7 +374,7 @@ default artifacts expiration setting, which you can find in the [CI/CD Admin set ...@@ -374,7 +374,7 @@ default artifacts expiration setting, which you can find in the [CI/CD Admin set
> Introduced in GitLab 10.3. > Introduced in GitLab 10.3.
To disable [the dependencies validation](../ci/yaml/README.md#when-a-dependent-job-will-fail), To disable [the dependencies validation](../ci/yaml/README.md#when-a-dependent-job-fails),
you can enable the `ci_disable_validates_dependencies` feature flag from a Rails console. you can enable the `ci_disable_validates_dependencies` feature flag from a Rails console.
**In Omnibus installations:** **In Omnibus installations:**
......
...@@ -181,7 +181,7 @@ To enable or disable the inheritance of all `variables:` or `default:` parameter ...@@ -181,7 +181,7 @@ To enable or disable the inheritance of all `variables:` or `default:` parameter
- `variables: true` or `variables: 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:` parameters or `variables:`, specify what
you wish to inherit, and any not listed will **not** be inherited. Use you wish to inherit. Anything not listed is **not** inherited. Use
one of the following formats: one of the following formats:
```yaml ```yaml
...@@ -344,9 +344,9 @@ workflow: ...@@ -344,9 +344,9 @@ workflow:
This example never allows pipelines for schedules or `push` (branches and tags) pipelines, This example never allows pipelines for schedules or `push` (branches and tags) pipelines,
but does allow pipelines in **all** other cases, *including* merge request pipelines. but does allow pipelines in **all** other cases, *including* merge request pipelines.
As with `rules` defined in jobs, be careful not to use a configuration that allows Be careful not to use a configuration that might run
merge request pipelines and branch pipelines to run at the same time, or you could merge request pipelines and branch pipelines at the same time. As with `rules` defined in jobs,
have [duplicate pipelines](#prevent-duplicate-pipelines). it can cause [duplicate pipelines](#prevent-duplicate-pipelines).
#### `workflow:rules` templates #### `workflow:rules` templates
...@@ -358,9 +358,9 @@ for common scenarios. These templates help prevent duplicate pipelines. ...@@ -358,9 +358,9 @@ for common scenarios. These templates help prevent duplicate pipelines.
The [`Branch-Pipelines` template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Workflows/Branch-Pipelines.gitlab-ci.yml) The [`Branch-Pipelines` template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Workflows/Branch-Pipelines.gitlab-ci.yml)
makes your pipelines run for branches and tags. makes your pipelines run for branches and tags.
Branch pipeline status is displayed within merge requests that use that branch Branch pipeline status is displayed within merge requests that use the branch
as a source, but this pipeline type does not support any features offered by as a source. However, this pipeline type does not support any features offered by
[Merge Request Pipelines](../merge_request_pipelines/) like [Merge Request Pipelines](../merge_request_pipelines/), like
[Pipelines for Merge Results](../merge_request_pipelines/#pipelines-for-merged-results) [Pipelines for Merge Results](../merge_request_pipelines/#pipelines-for-merged-results)
or [Merge Trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/). or [Merge Trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/).
Use this template if you are intentionally avoiding those features. Use this template if you are intentionally avoiding those features.
...@@ -1529,7 +1529,7 @@ docker build: ...@@ -1529,7 +1529,7 @@ docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG . script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules: rules:
- if: '$VAR == "string value"' - if: '$VAR == "string value"'
changes: # Will include the job and set to when:manual if any of the follow paths match a modified file. changes: # Include the job and set to when:manual if any of the follow paths match a modified file.
- Dockerfile - Dockerfile
- docker/scripts/* - docker/scripts/*
when: manual when: manual
...@@ -1730,7 +1730,7 @@ the pipeline if the following is true: ...@@ -1730,7 +1730,7 @@ the pipeline if the following is true:
- `(any listed refs are true) AND (any listed variables are true) AND (any listed changes are true) AND (any chosen Kubernetes status matches)` - `(any listed refs are true) AND (any listed variables are true) AND (any listed changes are true) AND (any chosen Kubernetes status matches)`
In the example below, the `test` job will `only` be created when **all** of the following are true: In the example below, the `test` job is `only` created when **all** of the following are true:
- The pipeline has been [scheduled](../pipelines/schedules.md) **or** runs for `master`. - The pipeline has been [scheduled](../pipelines/schedules.md) **or** runs for `master`.
- The `variables` keyword matches. - The `variables` keyword matches.
...@@ -1889,7 +1889,7 @@ the `docker build` job is created, but only if changes were made to any of the f ...@@ -1889,7 +1889,7 @@ the `docker build` job is created, but only if changes were made to any of the f
CAUTION: **Warning:** CAUTION: **Warning:**
If you use `only:changes` with [only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds), If you use `only:changes` with [only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds),
undesired behavior can result if you don't [also use `only:merge_requests`](#using-onlychanges-with-pipelines-for-merge-requests). you should [also use `only:merge_requests`](#using-onlychanges-with-pipelines-for-merge-requests). Otherwise it may not work as expected.
You can also use glob patterns to match multiple files in either the root directory You can also use glob patterns to match multiple files in either the root directory
of the repository, or in _any_ directory within the repository. However, they must be wrapped of the repository, or in _any_ directory within the repository. However, they must be wrapped
...@@ -1949,13 +1949,9 @@ docker build service one: ...@@ -1949,13 +1949,9 @@ docker build service one:
- service-one/**/* - service-one/**/*
``` ```
In the scenario above, if a merge request is created or updated that changes In this scenario, if a merge request changes
either files in `service-one` directory or the `Dockerfile`, GitLab creates files in the `service-one` directory or the `Dockerfile`, GitLab creates
and triggers the `docker build service one` job. the `docker build service one` job.
Note that if [pipelines for merge requests](../merge_request_pipelines/index.md) is
combined with `only: [change]`, but `only: [merge_requests]` is omitted, there could be
unwanted behavior.
For example: For example:
...@@ -2776,8 +2772,8 @@ The cache is shared between jobs, so if you're using different ...@@ -2776,8 +2772,8 @@ The cache is shared between jobs, so if you're using different
paths for different jobs, you should also set a different `cache:key`. paths for different jobs, you should also set a different `cache:key`.
Otherwise cache content can be overwritten. Otherwise cache content can be overwritten.
The `key` parameter defines the affinity of caching between jobs, The `key` parameter defines the affinity of caching between jobs.
to have a single cache for all jobs, cache per-job, cache per-branch 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, 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. including caching data between different jobs or even different branches.
...@@ -3381,7 +3377,7 @@ deploy: ...@@ -3381,7 +3377,7 @@ deploy:
script: make deploy script: make deploy
``` ```
##### When a dependent job will fail ##### When a dependent job fails
> Introduced in GitLab 10.3. > Introduced in GitLab 10.3.
...@@ -3772,10 +3768,10 @@ starting, which reduces parallelization. ...@@ -3772,10 +3768,10 @@ starting, which reduces parallelization.
#### Trigger a pipeline by API call #### Trigger a pipeline by API call
Triggers can be used to force a rebuild of a specific branch, tag or commit, To force a rebuild of a specific branch, tag, or commit, you can use an API call
with an API call when a pipeline gets created using a trigger token. with a trigger token.
Not to be confused with the [`trigger`](#trigger) parameter. The trigger token is different than the [`trigger`](#trigger) parameter.
[Read more in the triggers documentation.](../triggers/README.md) [Read more in the triggers documentation.](../triggers/README.md)
...@@ -3818,7 +3814,7 @@ step-2: ...@@ -3818,7 +3814,7 @@ step-2:
step-3: step-3:
stage: stage3 stage: stage3
script: script:
- echo "Because step-2 can not be canceled, this step will never be canceled, even though set as interruptible." - echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
interruptible: true interruptible: true
``` ```
...@@ -3837,7 +3833,7 @@ Sometimes running multiple jobs or pipelines at the same time in an environment ...@@ -3837,7 +3833,7 @@ Sometimes running multiple jobs or pipelines at the same time in an environment
can lead to errors during the deployment. can lead to errors during the deployment.
To avoid these errors, the `resource_group` attribute can be used to ensure that To avoid these errors, the `resource_group` attribute can be used to ensure that
the runner doesn't run certain jobs simultaneously. Resource groups behave similiar the runner doesn't run certain jobs simultaneously. Resource groups behave similar
to semaphores in other programming languages. to semaphores in other programming languages.
When the `resource_group` key is defined for a job in `.gitlab-ci.yml`, When the `resource_group` key is defined for a job in `.gitlab-ci.yml`,
...@@ -4003,7 +3999,7 @@ tags. These options cannot be used together, so choose one: ...@@ -4003,7 +3999,7 @@ tags. These options cannot be used together, so choose one:
- 'm1' - 'm1'
- 'm2' - 'm2'
- 'm3' - 'm3'
released_at: '2020-07-15T08:00:00Z' # Optional, will auto generate if not defined, or can use a variable. released_at: '2020-07-15T08:00:00Z' # Optional, is auto generated if not defined, or can use a variable.
``` ```
- To create a release automatically when commits are pushed or merged to the default branch, - To create a release automatically when commits are pushed or merged to the default branch,
...@@ -4049,7 +4045,7 @@ tags. These options cannot be used together, so choose one: ...@@ -4049,7 +4045,7 @@ tags. These options cannot be used together, so choose one:
- 'm1' - 'm1'
- 'm2' - 'm2'
- 'm3' - 'm3'
released_at: '2020-07-15T08:00:00Z' # Optional, will auto generate if not defined, or can use a variable. released_at: '2020-07-15T08:00:00Z' # Optional, is auto generated if not defined, or can use a variable.
``` ```
#### Release assets as Generic packages #### Release assets as Generic packages
......
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