Merge branch 'docs-yaml-consistent-colons' into 'master'

Remove extra colons from keywords

See merge request gitlab-org/gitlab!75602

doc/administration/cicd.md

@@ -58,9 +58,9 @@ For Omnibus GitLab installations:
    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)
 can choose a custom limit. For example, to set the limit to `100`:

doc/ci/caching/index.md

@@ -27,7 +27,7 @@ can't link to files outside it.
 
 ### 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 jobs in the same pipeline can use the cache, if the dependencies are identical.
 - Different projects cannot share the cache.

doc/ci/directed_acyclic_graph/index.md

@@ -66,9 +66,9 @@ as quickly as possible.
 
 ## 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.
 
 ## Limitations
@@ -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.
 
-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)
 

doc/ci/environments/index.md

@@ -294,7 +294,7 @@ As soon as the `review` job finishes, GitLab updates the `review/your-branch-nam
 environment's URL.
 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.
-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
 `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
 Note the following:
 
 - `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.
 - If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update
   the environment URL.
@@ -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.
 
-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.
 
 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:
 
 - `when`, defined at either:
   - [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
     even if the job doesn't run.
 - `environment:name`

doc/ci/jobs/job_control.md

@@ -79,7 +79,7 @@ job:
 - In **all other cases**, the job is added to the pipeline, with `when: on_success`.
 
 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
 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)
@@ -153,7 +153,7 @@ To avoid duplicate pipelines, you can:
 - Use [`workflow`](../yaml/index.md#workflow) to specify which types of pipelines
   can run.
 - 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
   job:
@@ -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
 as a single conjoined expression. That is:
 
-- `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.
+- `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.
 
 With `only`, individual keys are logically joined by an `AND`. A job is added to
 the pipeline if the following is true:

doc/ci/migration/jenkins.md

@@ -146,15 +146,15 @@ as well.
 
 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
-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
 and avoids some of the problem of unconstrained complexity which can make your Jenkinsfile hard to understand
 and manage.
 
 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
-[reuse configuration in your jobs](../yaml/index.md#extends), and `include:` can
+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
 be used to [reuse pipeline configurations](../yaml/index.md#include) in pipelines
 in different projects:
 
@@ -174,7 +174,7 @@ rspec:
 ## Artifact publishing
 
 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
 [artifacts documentation](../pipelines/job_artifacts.md):
 
@@ -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)
 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
-[`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
 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

@@ -112,11 +112,11 @@ C:
     - 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
   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
 save resources.
 

doc/ci/pipelines/multi_project_pipelines.md

@@ -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`
-   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:
 
    ```yaml

doc/ci/pipelines/parent_child_pipelines.md

@@ -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
   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.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
@@ -84,7 +84,7 @@ microservice_a:
         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),
 we can set the parent pipeline to depend on the status of the child pipeline upon completion:

doc/ci/pipelines/pipeline_architectures.md

@@ -211,7 +211,7 @@ trigger_b:
 ```
 
 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
 stages:
@@ -240,7 +240,7 @@ deploy_a:
 ```
 
 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
 stages:

doc/ci/pipelines/settings.md

@@ -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:
 
-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. Expand **Merge request approvals**.
 1. Select **Enable** next to the `Coverage-Check` approval rule.

doc/ci/services/gitlab.md

@@ -28,7 +28,7 @@ NOTE:
 Variables set in the GitLab UI are not passed down to the service containers.
 [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
 [How services are linked to the job](../docker/using_docker_images.md#extended-docker-configuration-options).

doc/ci/triggers/index.md

@@ -23,7 +23,7 @@ depending on which trigger method is used.
 
 | `$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 |
 
 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

@@ -291,7 +291,7 @@ Pipeline configuration warnings are shown when you:
 
 ### "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
 a branch that has an open merge request associated with it.
 

doc/ci/yaml/script.md

@@ -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)
   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.
 For example, commands that contain a colon (`:`) must be wrapped in single quotes (`'`).
@@ -101,7 +101,7 @@ WARNING:
 If multiple commands are combined into one command string, only the last command's
 failure or success is reported.
 [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.
 
 You can use the `|` (literal) YAML multiline block scalar indicator to write