Merge branch 'JonstonChan-fix-gitlab-ci-yml' into 'master'

Docs: change `gitlab-ci.yml` to `.gitlab-ci.yml`

See merge request gitlab-org/gitlab!69267

doc/ci/cloud_deployment/index.md

@@ -95,7 +95,7 @@ GitLab provides a series of [CI templates that you can include in your project](
 To automate deployments of your application to your [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AWS ECS)
 cluster, you can `include` the `AWS/Deploy-ECS.gitlab-ci.yml` template in your `.gitlab-ci.yml` file.
 
-GitLab also provides [Docker images](https://gitlab.com/gitlab-org/cloud-deploy/-/tree/master/aws) that can be used in your `gitlab-ci.yml` file to simplify working with AWS:
+GitLab also provides [Docker images](https://gitlab.com/gitlab-org/cloud-deploy/-/tree/master/aws) that can be used in your `.gitlab-ci.yml` file to simplify working with AWS:
 
 - Use `registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest` to use AWS CLI commands.
 - Use `registry.gitlab.com/gitlab-org/cloud-deploy/aws-ecs:latest` to deploy your application to AWS ECS.

doc/ci/environments/deployment_safety.md

@@ -136,10 +136,10 @@ connect the CD project to your development projects by using [multi-project pipe
 
 A `.gitlab-ci.yml` may contain rules to deploy an application to the production server. This
 deployment usually runs automatically after pushing a merge request. To prevent developers from
-changing the `gitlab-ci.yml`, you can define it in a different repository. The configuration can
+changing the `.gitlab-ci.yml`, you can define it in a different repository. The configuration can
 reference a file in another project with a completely different set of permissions (similar to
 [separating a project for deployments](#separate-project-for-deployments)).
-In this scenario, the `gitlab-ci.yml` is publicly accessible, but can only be edited by users with
+In this scenario, the `.gitlab-ci.yml` is publicly accessible, but can only be edited by users with
 appropriate permissions in the other project.
 
 For more information, see [Custom CI/CD configuration path](../pipelines/settings.md#specify-a-custom-cicd-configuration-file).

doc/ci/environments/incremental_rollouts.md

@@ -135,5 +135,5 @@ to switch to a different deployment. Both deployments are running in parallel, a
 can be switched to at any time.
 
 An [example deployable application](https://gitlab.com/gl-release/blue-green-example)
-is available, with a [`gitlab-ci.yml` CI/CD configuration file](https://gitlab.com/gl-release/blue-green-example/blob/master/.gitlab-ci.yml)
+is available, with a [`.gitlab-ci.yml` CI/CD configuration file](https://gitlab.com/gl-release/blue-green-example/blob/master/.gitlab-ci.yml)
 that demonstrates blue-green deployments.

doc/ci/environments/index.md

@@ -177,7 +177,7 @@ You can find the play button in the pipelines, environments, deployments, and jo
 
 If you are deploying to a [Kubernetes cluster](../../user/project/clusters/index.md)
 associated with your project, you can configure these deployments from your
-`gitlab-ci.yml` file.
+`.gitlab-ci.yml` file.
 
 NOTE:
 Kubernetes configuration isn't supported for Kubernetes clusters that are

doc/ci/environments/protected_environments.md

@@ -251,7 +251,7 @@ To protect a group-level environment:
 
 1. Make sure your environments have the correct
    [`deployment_tier`](index.md#deployment-tier-of-environments) defined in
-   `gitlab-ci.yml`.
+   `.gitlab-ci.yml`.
 1. Configure the group-level protected environments via the
    [REST API](../../api/group_protected_environments.md).
 

doc/ci/pipeline_editor/index.md

@@ -56,7 +56,7 @@ reflected in the CI lint. It displays the same results as the existing [CI Lint
 > - [Moved to **CI/CD > Editor**](https://gitlab.com/gitlab-org/gitlab/-/issues/263141) in GitLab 13.7.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/290117) in GitLab 13.12.
 
-To view a visualization of your `gitlab-ci.yml` configuration, in your project,
+To view a visualization of your `.gitlab-ci.yml` configuration, in your project,
 go to **CI/CD > Editor**, and then select the **Visualize** tab. The
 visualization shows all stages and jobs. Any [`needs`](../yaml/index.md#needs)
 relationships are displayed as lines connecting jobs together, showing the

doc/ci/troubleshooting.md

@@ -29,7 +29,7 @@ with your editor of choice.
 ### Verify syntax with CI Lint tool
 
 The [CI Lint tool](lint.md) is a simple way to ensure the syntax of a CI/CD configuration
-file is correct. Paste in full `gitlab-ci.yml` files or individual jobs configuration,
+file is correct. Paste in full `.gitlab-ci.yml` files or individual jobs configuration,
 to verify the basic syntax.
 
 When a `.gitlab-ci.yml` file is present in a project, you can also use the CI Lint
@@ -49,7 +49,7 @@ and check if their values are what you expect.
 
 ## GitLab CI/CD documentation
 
-The [complete `gitlab-ci.yml` reference](yaml/index.md) contains a full list of
+The [complete `.gitlab-ci.yml` reference](yaml/index.md) contains a full list of
 every keyword you may need to use to configure your pipelines.
 
 You can also look at a large number of pipeline configuration [examples](examples/index.md)

doc/ci/yaml/index.md

@@ -386,7 +386,7 @@ does not block triggered pipelines.
 > [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/42861) to GitLab Free in 11.4.
 
 Use `include` to include external YAML files in your CI/CD configuration.
-You can break down one long `gitlab-ci.yml` file into multiple files to increase readability,
+You can break down one long `.gitlab-ci.yml` file into multiple files to increase readability,
 or reduce duplication of the same configuration in multiple places.
 
 You can also store template files in a central repository and `include` them in projects.
@@ -4483,7 +4483,7 @@ deploy_review_job:
 
 You can use only integers and strings for the variable's name and value.
 
-If you define a variable at the top level of the `gitlab-ci.yml` file, it is global,
+If you define a variable at the top level of the `.gitlab-ci.yml` file, it is global,
 meaning it applies to all jobs. If you define a variable in a job, it's available
 to that job only.
 

doc/user/application_security/dast/index.md

@@ -74,7 +74,7 @@ If your application utilizes Docker containers you have another option for deplo
 After your Docker build job completes and your image is added to your container registry, you can use the image as a
 [service](../../../ci/services/index.md).
 
-By using service definitions in your `gitlab-ci.yml`, you can scan services with the DAST analyzer.
+By using service definitions in your `.gitlab-ci.yml`, you can scan services with the DAST analyzer.
 
 ```yaml
 stages:
@@ -1307,9 +1307,9 @@ dast:
 By default, DAST downloads all artifacts defined by previous jobs in the pipeline. If
 your DAST job does not rely on `environment_url.txt` to define the URL under test or any other files created
 in previous jobs, we recommend you don't download artifacts. To avoid downloading
-artifacts, add the following to your `gitlab-ci.yml` file:
+artifacts, add the following to your `.gitlab-ci.yml` file:
 
-```json
+```yaml
 dast:
    dependencies: []
 ```

doc/user/application_security/offline_deployments/index.md

@@ -111,7 +111,7 @@ example of such a transfer:
 GitLab provides a [vendored template](../../../ci/yaml/index.md#includetemplate)
 to ease this process.
 
-This template should be used in a new, empty project, with a `gitlab-ci.yml` file containing:
+This template should be used in a new, empty project, with a `.gitlab-ci.yml` file containing:
 
 ```yaml
 include:

doc/user/project/clusters/serverless/index.md

@@ -316,7 +316,7 @@ The optional `runtime` parameter can refer to one of the following runtime alias
 | `openfaas/classic/python3` | OpenFaaS |
 | `openfaas/classic/ruby` | OpenFaaS |
 
-After the `gitlab-ci.yml` template has been added and the `serverless.yml` file
+After the `.gitlab-ci.yml` template has been added and the `serverless.yml` file
 has been created, pushing a commit to your project results in a CI pipeline
 being executed which deploys each function as a Knative service. After the
 deploy stage has finished, additional details for the function display

doc/user/project/merge_requests/test_coverage_visualization.md

@@ -129,7 +129,7 @@ The `source` is ignored if the path does not follow this pattern. The parser ass
 
 ### JavaScript example
 
-The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example uses [Mocha](https://mochajs.org/)
+The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example uses [Mocha](https://mochajs.org/)
 JavaScript testing and [nyc](https://github.com/istanbuljs/nyc) coverage-tooling to
 generate the coverage artifact:
 
@@ -147,7 +147,7 @@ test:
 
 #### Maven example
 
-The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example for Java or Kotlin uses [Maven](https://maven.apache.org/)
+The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for Java or Kotlin uses [Maven](https://maven.apache.org/)
 to build the project and [JaCoCo](https://www.eclemma.org/jacoco/) coverage-tooling to
 generate the coverage artifact.
 You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image.
@@ -185,7 +185,7 @@ coverage-jdk11:
 
 #### Gradle example
 
-The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example for Java or Kotlin uses [Gradle](https://gradle.org/)
+The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for Java or Kotlin uses [Gradle](https://gradle.org/)
 to build the project and [JaCoCo](https://www.eclemma.org/jacoco/) coverage-tooling to
 generate the coverage artifact.
 You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image.
@@ -223,7 +223,7 @@ coverage-jdk11:
 
 ### Python example
 
-The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example for Python uses [pytest-cov](https://pytest-cov.readthedocs.io/) to collect test coverage data and [coverage.py](https://coverage.readthedocs.io/) to convert the report to use full relative paths.
+The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for Python uses [pytest-cov](https://pytest-cov.readthedocs.io/) to collect test coverage data and [coverage.py](https://coverage.readthedocs.io/) to convert the report to use full relative paths.
 The information isn't displayed without the conversion.
 
 This example assumes that the code for your package is in `src/` and your tests are in `tests.py`:
@@ -243,7 +243,7 @@ run tests:
 
 ### C/C++ example
 
-The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example for C/C++ with
+The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for C/C++ with
 `gcc` or `g++` as the compiler uses [`gcovr`](https://gcovr.com/en/stable/) to generate the coverage
 output file in Cobertura XML format.
 

doc/user/project/pages/index.md

@@ -46,7 +46,7 @@ To create a GitLab Pages website:
 
 | Document | Description |
 | -------- | ----------- |
-| [Create a `gitlab-ci.yml` file from scratch](getting_started/pages_from_scratch.md)    | Add a Pages site to an existing project. Learn how to create and configure your own CI file. |
+| [Create a `.gitlab-ci.yml` file from scratch](getting_started/pages_from_scratch.md)    | Add a Pages site to an existing project. Learn how to create and configure your own CI file. |
 | [Use a `.gitlab-ci.yml` template](getting_started/pages_ci_cd_template.md) | Add a Pages site to an existing project. Use a pre-populated CI template file. |
 | [Fork a sample project](getting_started/pages_forked_sample_project.md)               | Create a new project with Pages already configured by forking a sample project. |
 | [Use a project template](getting_started/pages_new_project_template.md)       | Create a new project with Pages already configured by using a template. |

doc/user/project/releases/index.md

@@ -200,7 +200,7 @@ If the job that's executing is within a freeze period, GitLab CI/CD creates an e
 variable named `$CI_DEPLOY_FREEZE`.
 
 To prevent the deployment job from executing, create a `rules` entry in your
-`gitlab-ci.yml`, for example:
+`.gitlab-ci.yml`, for example:
 
 ```yaml
 deploy_to_production: