Add latest changes from gitlab-org/gitlab@14-1-stable-eev14.1.0-rc42

3 files changed, 20 insertions, 20 deletions

diff --git a/doc/development/cicd/cicd_reference_documentation_guide.md b/doc/development/cicd/cicd_reference_documentation_guide.md
index 14a313daba8..33bc416d8bc 100644
--- a/doc/development/cicd/cicd_reference_documentation_guide.md
+++ b/doc/development/cicd/cicd_reference_documentation_guide.md
@@ -4,7 +4,7 @@ group: Pipeline Execution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# CI/CD YAML reference style guide
+# CI/CD YAML reference style guide **(FREE)**
 
 The CI/CD YAML reference uses a standard style to make it easier to use and update.
 
@@ -91,7 +91,7 @@ Keyword description and main details.
 
 ### YAML reference style example
 
-See the [`only:changes` / `except:changes`](../../ci/yaml/README.md#onlychanges--exceptchanges)
+See the [`only:changes` / `except:changes`](../../ci/yaml/index.md#onlychanges--exceptchanges)
 documentation for an example of the YAML reference style. The following example is a
 shortened version of that documentation's Markdown:
 
diff --git a/doc/development/cicd/index.md b/doc/development/cicd/index.md
index 025d63f4a62..6d4e19d8196 100644
--- a/doc/development/cicd/index.md
+++ b/doc/development/cicd/index.md
@@ -5,14 +5,14 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: index, concepts, howto
 ---
 
-# CI/CD development documentation
+# CI/CD development documentation **(FREE)**
 
 Development guides that are specific to CI/CD are listed here.
 
 If you are creating new CI/CD templates, please read [the development guide for GitLab CI/CD templates](templates.md).
 
 See the [CI/CD YAML reference documentation guide](cicd_reference_documentation_guide.md)
-to learn how to update the [reference page](../../ci/yaml/README.md).
+to learn how to update the [reference page](../../ci/yaml/index.md).
 
 ## CI Architecture overview
 
@@ -27,13 +27,13 @@ On the left side we have the events that can trigger a pipeline based on various
 - A `git push` is the most common event that triggers a pipeline.
 - The [Web API](../../api/pipelines.md#create-a-new-pipeline).
 - A user clicking the "Run pipeline" button in the UI.
-- When a [merge request is created or updated](../../ci/merge_request_pipelines/index.md#pipelines-for-merge-requests).
-- When an MR is added to a [Merge Train](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md#merge-trains).
+- When a [merge request is created or updated](../../ci/pipelines/merge_request_pipelines.md#pipelines-for-merge-requests).
+- When an MR is added to a [Merge Train](../../ci/pipelines/merge_trains.md#merge-trains).
 - A [scheduled pipeline](../../ci/pipelines/schedules.md#pipeline-schedules).
-- When project is [subscribed to an upstream project](../../ci/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt).
+- When project is [subscribed to an upstream project](../../ci/pipelines/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt).
 - When [Auto DevOps](../../topics/autodevops/index.md) is enabled.
 - When GitHub integration is used with [external pull requests](../../ci/ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests).
-- When an upstream pipeline contains a [bridge job](../../ci/yaml/README.md#trigger) which triggers a downstream pipeline.
+- When an upstream pipeline contains a [bridge job](../../ci/yaml/index.md#trigger) which triggers a downstream pipeline.
 
 Triggering any of these events invokes the [`CreatePipelineService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/create_pipeline_service.rb)
 which takes as input event data and the user triggering it, then attempts to create a pipeline.
@@ -42,7 +42,7 @@ The `CreatePipelineService` relies heavily on the [`YAML Processor`](https://git
 component, which is responsible for taking in a YAML blob as input and returns the abstract data structure of a
 pipeline (including stages and all jobs). This component also validates the structure of the YAML while
 processing it, and returns any syntax or semantic errors. The `YAML Processor` component is where we define
-[all the keywords](../../ci/yaml/README.md) available to structure a pipeline.
+[all the keywords](../../ci/yaml/index.md) available to structure a pipeline.
 
 The `CreatePipelineService` receives the abstract data structure returned by the `YAML Processor`,
 which then converts it to persisted models (pipeline, stages, jobs, etc.). After that, the pipeline is ready
@@ -61,7 +61,7 @@ successfully or fail. Each status transition for job within a pipeline triggers
 looks for the next jobs to be transitioned towards completion. While doing that, `ProcessPipelineService`
 updates the status of jobs, stages and the overall pipeline.
 
-On the right side of the diagram we have a list of [runners](../../ci/runners/README.md)
+On the right side of the diagram we have a list of [runners](../../ci/runners/index.md)
 connected to the GitLab instance. These can be shared runners, group runners, or project-specific runners.
 The communication between runners and the Rails server occurs through a set of API endpoints, grouped as
 the `Runner API Gateway`.
@@ -79,12 +79,12 @@ case the runner downloads them using a dedicated API endpoint.
 Artifacts are stored in object storage, while metadata is kept in the database. An important example of artifacts
 are reports (JUnit, SAST, DAST, etc.) which are parsed and rendered in the merge request.
 
-Job status transitions are not all automated. A user may run [manual jobs](../../ci/yaml/README.md#whenmanual), cancel a pipeline, retry
+Job status transitions are not all automated. A user may run [manual jobs](../../ci/yaml/index.md#whenmanual), cancel a pipeline, retry
 specific failed jobs or the entire pipeline. Anything that
 causes a job to change status triggers `ProcessPipelineService`, as it's responsible for
 tracking the status of the entire pipeline.
 
-A special type of job is the [bridge job](../../ci/yaml/README.md#trigger) which is executed server-side
+A special type of job is the [bridge job](../../ci/yaml/index.md#trigger) which is executed server-side
 when transitioning to the `pending` state. This job is responsible for creating a downstream pipeline, such as
 a multi-project or child pipeline. The workflow loop starts again
 from the `CreatePipelineService` every time a downstream pipeline is triggered.
diff --git a/doc/development/cicd/templates.md b/doc/development/cicd/templates.md
index 8331985697e..204287d7b59 100644
--- a/doc/development/cicd/templates.md
+++ b/doc/development/cicd/templates.md
@@ -7,7 +7,7 @@ type: index, concepts, howto
 
 # Development guide for GitLab CI/CD templates
 
-This document explains how to develop [GitLab CI/CD templates](../../ci/examples/README.md).
+This document explains how to develop [GitLab CI/CD templates](../../ci/examples/index.md).
 
 ## Requirements for CI/CD templates
 
@@ -16,7 +16,7 @@ Before submitting a merge request with a new or updated CI/CD template, you must
 - Place the template in the correct [directory](#template-directories).
 - Follow the [CI/CD template authoring guidelines](#template-authoring-guidelines).
 - Name the template following the `*.gitlab-ci.yml` format.
-- Use valid [`.gitlab-ci.yml` syntax](../../ci/yaml/README.md). Verify it's valid
+- Use valid [`.gitlab-ci.yml` syntax](../../ci/yaml/index.md). Verify it's valid
   with the [CI/CD lint tool](../../ci/lint.md).
 - Include [a changelog](../changelog.md) if the merge request introduces a user-facing change.
 - Follow the [template review process](#contribute-cicd-template-merge-requests).
@@ -59,8 +59,8 @@ don't have any other `.gitlab-ci.yml` files.
 
 When authoring pipeline templates:
 
-- Place any [global keywords](../../ci/yaml/README.md#global-keywords) like `image`
-  or `before_script` in a [`default`](../../ci/yaml/README.md#custom-default-keyword-values)
+- Place any [global keywords](../../ci/yaml/index.md#global-keywords) like `image`
+  or `before_script` in a [`default`](../../ci/yaml/index.md#custom-default-keyword-values)
   section at the top of the template.
 - Note clearly in the [code comments](#explain-the-template-with-comments) if the
   template is designed to be used with the `includes` keyword in an existing
@@ -68,7 +68,7 @@ When authoring pipeline templates:
 
 A **job template** provides specific jobs that can be added to an existing CI/CD
 workflow to accomplish specific tasks. It usually should be used by adding it to
-an existing `.gitlab-ci.yml` file by using the [`includes`](../../ci/yaml/README.md#global-keywords)
+an existing `.gitlab-ci.yml` file by using the [`includes`](../../ci/yaml/index.md#global-keywords)
 keyword. You can also copy and paste the contents into an existing `.gitlab-ci.yml` file.
 
 Configure job templates so that users can add them to their current pipeline with very
@@ -77,7 +77,7 @@ other pipeline configuration.
 
 When authoring job templates:
 
-- Do not use [global](../../ci/yaml/README.md#global-keywords) or [`default`](../../ci/yaml/README.md#custom-default-keyword-values)
+- Do not use [global](../../ci/yaml/index.md#global-keywords) or [`default`](../../ci/yaml/index.md#custom-default-keyword-values)
   keywords. When a root `.gitlab-ci.yml` includes a template, global or default keywords
   might be overridden and cause unexpected behavior. If a job template requires a
   specific stage, explain in the code comments that users must manually add the stage
@@ -127,8 +127,8 @@ job2:
 
 #### Use `rules` instead of `only` or `except`
 
-Avoid using [`only` or `except`](../../ci/yaml/README.md#only--except) if possible.
-Only and except is not being developed any more, and [`rules`](../../ci/yaml/README.md#rules)
+Avoid using [`only` or `except`](../../ci/yaml/index.md#only--except) if possible.
+Only and except is not being developed any more, and [`rules`](../../ci/yaml/index.md#rules)
 is now the preferred syntax:
 
 ```yaml