Add latest changes from gitlab-org/gitlab@master

7 files changed, 21 insertions, 21 deletions

diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index e8dda75cf21..5041b56bba7 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -67,9 +67,9 @@ Pipelines can be configured in many different ways:
 Pipelines and their component jobs and stages are defined in the CI/CD pipeline configuration file for each project.
 
 - [Jobs](../jobs/index.md) are the basic configuration component.
-- Stages are defined by using the [`stages`](../yaml/README.md#stages) keyword.
+- Stages are defined by using the [`stages`](../yaml/index.md#stages) keyword.
 
-For a list of configuration options in the CI pipeline file, see the [GitLab CI/CD Pipeline Configuration Reference](../yaml/README.md).
+For a list of configuration options in the CI pipeline file, see the [GitLab CI/CD Pipeline Configuration Reference](../yaml/index.md).
 
 You can also configure specific aspects of your pipelines through the GitLab UI. For example:
 
@@ -146,7 +146,7 @@ The pipeline now executes the jobs as configured.
 
 > [Introduced in](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) GitLab 13.7.
 
-You can use the [`value` and `description`](../yaml/README.md#prefill-variables-in-manual-pipelines)
+You can use the [`value` and `description`](../yaml/index.md#prefill-variables-in-manual-pipelines)
 keywords to define
 [pipeline-level (global) variables](../variables/index.md#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file)
 that are prefilled when running a pipeline manually.
@@ -200,7 +200,7 @@ For each `var` or `file_var`, a key and value are required.
 
 ### Add manual interaction to your pipeline
 
-Manual actions, configured using the [`when:manual`](../yaml/README.md#whenmanual) keyword,
+Manual actions, configured using the [`when:manual`](../yaml/index.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
@@ -347,7 +347,7 @@ You can group the jobs by:
   ![jobs grouped by stage](img/pipelines_graph_stage_view_v13_12.png)
 
 - [Job dependencies](#view-job-dependencies-in-the-pipeline-graph), which arranges
-  jobs based on their [`needs`](../yaml/README.md#needs) dependencies.
+  jobs based on their [`needs`](../yaml/index.md#needs) dependencies.
 
 [Multi-project pipeline graphs](../multi_project_pipelines.md#multi-project-pipeline-visualization) help
 you visualize the entire pipeline, including all cross-project inter-dependencies. **(PREMIUM)**
@@ -365,7 +365,7 @@ This in-development feature might not be available for your use. There can be
 [risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
-You can arrange jobs in the pipeline graph based on their [`needs`](../yaml/README.md#needs)
+You can arrange jobs in the pipeline graph based on their [`needs`](../yaml/index.md#needs)
 dependencies.
 
 Jobs in the leftmost column run first, and jobs that depend on them are grouped in the next columns.
diff --git a/doc/ci/pipelines/job_artifacts.md b/doc/ci/pipelines/job_artifacts.md
index 0c4f52142ac..eed30648b75 100644
--- a/doc/ci/pipelines/job_artifacts.md
+++ b/doc/ci/pipelines/job_artifacts.md
@@ -48,7 +48,7 @@ is used.
 If you run two types of pipelines (like branch and scheduled) for the same ref,
 the pipeline that finishes later creates the job artifact.
 
-For more examples, view the [keyword reference for the `.gitlab-ci.yml` file](../yaml/README.md#artifacts).
+For more examples, view the [keyword reference for the `.gitlab-ci.yml` file](../yaml/index.md#artifacts).
 
 ## Download job artifacts
 
@@ -173,7 +173,7 @@ https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/main/file/htmlcov/index.ht
 
 ## When job artifacts are deleted
 
-See the [`expire_in`](../yaml/README.md#artifactsexpire_in) documentation for information on when
+See the [`expire_in`](../yaml/index.md#artifactsexpire_in) documentation for information on when
 job artifacts are deleted.
 
 ### Keep artifacts from most recent successful jobs
diff --git a/doc/ci/pipelines/pipeline_architectures.md b/doc/ci/pipelines/pipeline_architectures.md
index 78031ec1d97..184bc5a956a 100644
--- a/doc/ci/pipelines/pipeline_architectures.md
+++ b/doc/ci/pipelines/pipeline_architectures.md
@@ -18,7 +18,7 @@ own advantages. These methods can be mixed and matched if needed:
 - [Child/Parent Pipelines](#child--parent-pipelines): Good for monorepos and projects with lots of independently defined components.
 
 For more details about
-any of the keywords used below, check out our [CI YAML reference](../yaml/README.md) for details.
+any of the keywords used below, check out our [CI YAML reference](../yaml/index.md) for details.
 
 ## Basic Pipelines
 
@@ -96,7 +96,7 @@ deploy_b:
 
 If efficiency is important to you and you want everything to run as quickly as possible,
 you can use [Directed Acyclic Graphs (DAG)](../directed_acyclic_graph/index.md). Use the
-[`needs` keyword](../yaml/README.md#needs) to define dependency relationships between
+[`needs` keyword](../yaml/index.md#needs) to define dependency relationships between
 your jobs. When GitLab knows the relationships between your jobs, it can run everything
 as fast as possible, and even skips into subsequent stages when possible.
 
@@ -163,12 +163,12 @@ deploy_b:
 
 In the examples above, it's clear we've got two types of things that could be built independently.
 This is an ideal case for using [Child / Parent Pipelines](../parent_child_pipelines.md)) via
-the [`trigger` keyword](../yaml/README.md#trigger). It separates out the configuration
+the [`trigger` keyword](../yaml/index.md#trigger). It separates out the configuration
 into multiple files, keeping things very simple. You can also combine this with:
 
-- The [`rules` keyword](../yaml/README.md#rules): For example, have the child pipelines triggered only
+- The [`rules` keyword](../yaml/index.md#rules): For example, have the child pipelines triggered only
   when there are changes to that area.
-- The [`include` keyword](../yaml/README.md#include): Bring in common behaviors, ensuring
+- The [`include` keyword](../yaml/index.md#include): Bring in common behaviors, ensuring
   you are not repeating yourself.
 - [DAG pipelines](#directed-acyclic-graph-pipelines) inside of child pipelines, achieving the benefits of both.
 
diff --git a/doc/ci/pipelines/pipeline_artifacts.md b/doc/ci/pipelines/pipeline_artifacts.md
index b80a056bbca..55555571f97 100644
--- a/doc/ci/pipelines/pipeline_artifacts.md
+++ b/doc/ci/pipelines/pipeline_artifacts.md
@@ -9,7 +9,7 @@ type: reference, howto
 
 Pipeline artifacts are files created by GitLab after a pipeline finishes. These are different than [job artifacts](job_artifacts.md) because they are not explicitly managed by the `.gitlab-ci.yml` definitions.
 
-Pipeline artifacts are used by the [test coverage visualization feature](../../user/project/merge_requests/test_coverage_visualization.md) to collect coverage information. It uses the [`artifacts: reports`](../yaml/README.md#artifactsreports) CI/CD keyword.
+Pipeline artifacts are used by the [test coverage visualization feature](../../user/project/merge_requests/test_coverage_visualization.md) to collect coverage information. It uses the [`artifacts: reports`](../yaml/index.md#artifactsreports) CI/CD keyword.
 
 ## Storage
 
diff --git a/doc/ci/pipelines/pipeline_efficiency.md b/doc/ci/pipelines/pipeline_efficiency.md
index 155b83f9d33..5d8d4fa8ff1 100644
--- a/doc/ci/pipelines/pipeline_efficiency.md
+++ b/doc/ci/pipelines/pipeline_efficiency.md
@@ -146,7 +146,7 @@ with embedded metric charts and all valuable details to analyze the problem.
 
 Review the storage use of the following to help analyze costs and efficiency:
 
-- [Job artifacts](job_artifacts.md) and their [`expire_in`](../yaml/README.md#artifactsexpire_in)
+- [Job artifacts](job_artifacts.md) and their [`expire_in`](../yaml/index.md#artifactsexpire_in)
   configuration. If kept for too long, storage usage grows and could slow pipelines down.
 - [Container registry](../../user/packages/container_registry/index.md) usage.
 - [Package registry](../../user/packages/package_registry/index.md) usage.
@@ -162,9 +162,9 @@ make pipelines run faster and more efficiently.
 Try to find which jobs don't need to run in all situations, and use pipeline configuration
 to stop them from running:
 
-- Use the [`interruptible`](../yaml/README.md#interruptible) keyword to stop old pipelines
+- Use the [`interruptible`](../yaml/index.md#interruptible) keyword to stop old pipelines
   when they are superseded by a newer pipeline.
-- Use [`rules`](../yaml/README.md#rules) to skip tests that aren't needed. For example,
+- Use [`rules`](../yaml/index.md#rules) to skip tests that aren't needed. For example,
   skip backend tests when only the frontend code is changed.
 - Run non-essential [scheduled pipelines](schedules.md) less frequently.
 
@@ -195,7 +195,7 @@ Another optimization method is to [cache](../caching/index.md) dependencies. If
 dependencies change rarely, like [NodeJS `/node_modules`](../caching/index.md#cache-nodejs-dependencies),
 caching can make pipeline execution much faster.
 
-You can use [`cache:when`](../yaml/README.md#cachewhen) to cache downloaded dependencies
+You can use [`cache:when`](../yaml/index.md#cachewhen) to cache downloaded dependencies
 even when a job fails.
 
 ### Docker Images
diff --git a/doc/ci/pipelines/schedules.md b/doc/ci/pipelines/schedules.md
index c6a40039816..9cb600ae551 100644
--- a/doc/ci/pipelines/schedules.md
+++ b/doc/ci/pipelines/schedules.md
@@ -52,14 +52,14 @@ is installed on.
 ### Using variables
 
 You can pass any number of arbitrary variables. They are available in
-GitLab CI/CD so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/README.md).
+GitLab CI/CD so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/index.md).
 
 ![Scheduled pipeline variables](img/pipeline_schedule_variables.png)
 
 ### Using `rules`
 
 To configure a job to be executed only when the pipeline has been
-scheduled, use the [`rules`](../yaml/README.md#rules) keyword.
+scheduled, use the [`rules`](../yaml/index.md#rules) keyword.
 
 In this example, `make world` runs in scheduled pipelines, and `make build`
 runs in branch and tag pipelines:
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 2e842856e55..683939ac81a 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -228,7 +228,7 @@ You can set pending or running pipelines to cancel automatically when a new pipe
 1. Check the **Auto-cancel redundant pipelines** checkbox.
 1. Click **Save changes**.
 
-Use the [`interruptible`](../yaml/README.md#interruptible) keyword to indicate if a
+Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
 running job can be cancelled before it completes.
 
 ## Skip outdated deployment jobs