Add latest changes from gitlab-org/gitlab@master

9 files changed, 512 insertions, 6 deletions

diff --git a/doc/ci/pipelines/img/multi_pipeline_mini_graph.gif b/doc/ci/pipelines/img/multi_pipeline_mini_graph.gif
new file mode 100644
index 00000000000..de49ba5aa12
--- /dev/null
+++ b/doc/ci/pipelines/img/multi_pipeline_mini_graph.gif
diff --git a/doc/ci/pipelines/img/multi_project_pipeline_graph.png b/doc/ci/pipelines/img/multi_project_pipeline_graph.png
new file mode 100644
index 00000000000..723a455cb4a
--- /dev/null
+++ b/doc/ci/pipelines/img/multi_project_pipeline_graph.png
diff --git a/doc/ci/pipelines/img/parent_pipeline_graph_expanded_v12_6.png b/doc/ci/pipelines/img/parent_pipeline_graph_expanded_v12_6.png
new file mode 100644
index 00000000000..db18cc201fc
--- /dev/null
+++ b/doc/ci/pipelines/img/parent_pipeline_graph_expanded_v12_6.png
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index 621ad4a60d9..feba310bf8f 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -50,8 +50,8 @@ Pipelines can be configured in many different ways:
   followed by the next stage.
 - [Directed Acyclic Graph Pipeline (DAG) pipelines](../directed_acyclic_graph/index.md) are based on relationships
   between jobs and can run more quickly than basic pipelines.
-- [Multi-project pipelines](../multi_project_pipelines.md) combine pipelines for different projects together.
-- [Parent-Child pipelines](../parent_child_pipelines.md) break down complex pipelines
+- [Multi-project pipelines](multi_project_pipelines.md) combine pipelines for different projects together.
+- [Parent-Child pipelines](parent_child_pipelines.md) break down complex pipelines
   into one parent pipeline that can trigger multiple child sub-pipelines, which all
   run in the same project and with the same SHA.
 - [Pipelines for Merge Requests](../pipelines/merge_request_pipelines.md) run for merge
@@ -349,7 +349,7 @@ You can group the jobs by:
 - [Job dependencies](#view-job-dependencies-in-the-pipeline-graph), which arranges
   jobs based on their [`needs`](../yaml/index.md#needs) dependencies.
 
-[Multi-project pipeline graphs](../multi_project_pipelines.md#multi-project-pipeline-visualization) help
+[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)**
 
 ### View job dependencies in the pipeline graph
diff --git a/doc/ci/pipelines/job_artifacts.md b/doc/ci/pipelines/job_artifacts.md
index eed30648b75..b9a42c76293 100644
--- a/doc/ci/pipelines/job_artifacts.md
+++ b/doc/ci/pipelines/job_artifacts.md
@@ -112,7 +112,7 @@ the artifact.
 ## How searching for job artifacts works
 
 In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201784) and later, artifacts
-for [parent and child pipelines](../parent_child_pipelines.md) are searched in hierarchical
+for [parent and child pipelines](parent_child_pipelines.md) are searched in hierarchical
 order from parent to child. For example, if both parent and child pipelines have a
 job with the same name, the job artifact from the parent pipeline is returned.
 
diff --git a/doc/ci/pipelines/multi_project_pipelines.md b/doc/ci/pipelines/multi_project_pipelines.md
new file mode 100644
index 00000000000..52939e75d4c
--- /dev/null
+++ b/doc/ci/pipelines/multi_project_pipelines.md
@@ -0,0 +1,314 @@
+---
+stage: Verify
+group: Pipeline Authoring
+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
+type: reference
+---
+
+# Multi-project pipelines **(FREE)**
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
+
+You can set up [GitLab CI/CD](../index.md) across multiple projects, so that a pipeline
+in one project can trigger a pipeline in another project. You can visualize the entire pipeline
+in one place, including all cross-project interdependencies.
+
+For example, you might deploy your web application from three different projects in GitLab.
+Each project has its own build, test, and deploy process. With multi-project pipelines you can
+visualize the entire pipeline, including all build and test stages for all three projects.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For an overview, see the [Multi-project pipelines demo](https://www.youtube.com/watch?v=g_PIwBM1J84).
+
+Multi-project pipelines are also useful for larger products that require cross-project interdependencies, like those
+with a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/).
+Learn more in the [Cross-project Pipeline Triggering and Visualization demo](https://about.gitlab.com/learn/)
+at GitLab@learn, in the Continuous Integration section.
+
+If you trigger a pipeline in a downstream private project, on the upstream project's pipelines page,
+you can view:
+
+- The name of the project.
+- The status of the pipeline.
+
+If you have a public project that can trigger downstream pipelines in a private project,
+make sure there are no confidentiality problems.
+
+## Create multi-project pipelines
+
+To create multi-project pipelines, you can:
+
+- [Define them in your `.gitlab-ci.yml` file](#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
+- [Use the API](#create-multi-project-pipelines-by-using-the-api).
+
+### Define multi-project pipelines in your `.gitlab-ci.yml` file
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
+
+When you create a multi-project pipeline in your `.gitlab-ci.yml` file,
+you create what is called a *trigger job*. For example:
+
+```yaml
+rspec:
+  stage: test
+  script: bundle exec rspec
+
+staging:
+  variables:
+    ENVIRONMENT: staging
+  stage: deploy
+  trigger: my/deployment
+```
+
+In this example, after the `rspec` job succeeds in the `test` stage,
+the `staging` trigger job starts. The initial status of this
+job is `pending`.
+
+GitLab then creates a downstream pipeline in the
+`my/deployment` project and, as soon as the pipeline is created, the
+`staging` job succeeds. The full path to the project is `my/deployment`.
+
+You can view the status for the pipeline, or you can display
+[the downstream pipeline's status instead](#mirror-status-of-a-triggered-pipeline-in-the-trigger-job).
+
+The user that creates the upstream pipeline must be able to create pipelines in the
+downstream project (`my/deployment`) too. If the downstream project is not found,
+or the user does not have [permission](../../user/permissions.md) to create a pipeline there,
+the `staging` job is marked as _failed_.
+
+#### Trigger job configuration keywords
+
+Trigger jobs can use only a limited set of the GitLab CI/CD [configuration keywords](../yaml/index.md).
+The keywords available for use in trigger jobs are:
+
+- [`trigger`](../yaml/index.md#trigger)
+- [`stage`](../yaml/index.md#stage)
+- [`allow_failure`](../yaml/index.md#allow_failure)
+- [`rules`](../yaml/index.md#rules)
+- [`only` and `except`](../yaml/index.md#only--except)
+- [`when`](../yaml/index.md#when) (only with a value of `on_success`, `on_failure`, or `always`)
+- [`extends`](../yaml/index.md#extends)
+- [`needs`](../yaml/index.md#needs)
+
+#### Specify a downstream pipeline branch
+
+You can specify a branch name for the downstream pipeline to use.
+GitLab uses the commit on the head of the branch to
+create the downstream pipeline.
+
+```yaml
+rspec:
+  stage: test
+  script: bundle exec rspec
+
+staging:
+  stage: deploy
+  trigger:
+    project: my/deployment
+    branch: stable-11-2
+```
+
+Use:
+
+- The `project` keyword to specify the full path to a downstream project.
+- The `branch` keyword to specify the name of a branch in the project specified by `project`.
+  [In GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/10126) and later, variable expansion is
+  supported.
+
+Pipelines triggered on a protected branch in a downstream project use the [role](../../user/permissions.md)
+of the user that ran the trigger job in the upstream project. If the user does not
+have permission to run CI/CD pipelines against the protected branch, the pipeline fails. See
+[pipeline security for protected branches](index.md#pipeline-security-on-protected-branches).
+
+#### Pass CI/CD variables to a downstream pipeline by using the `variables` keyword
+
+Sometimes you might want to pass CI/CD variables to a downstream pipeline.
+You can do that by using the `variables` keyword, just like you would for any other job.
+
+```yaml
+rspec:
+  stage: test
+  script: bundle exec rspec
+
+staging:
+  variables:
+    ENVIRONMENT: staging
+  stage: deploy
+  trigger: my/deployment
+```
+
+The `ENVIRONMENT` variable is passed to every job defined in a downstream
+pipeline. It is available as a variable when GitLab Runner picks a job.
+
+In the following configuration, the `MY_VARIABLE` variable is passed to the downstream pipeline
+that is created when the `trigger-downstream` job is queued. This is because `trigger-downstream`
+job inherits variables declared in global variables blocks, and then we pass these variables to a downstream pipeline.
+
+```yaml
+variables:
+  MY_VARIABLE: my-value
+
+trigger-downstream:
+  variables:
+    ENVIRONMENT: something
+  trigger: my/project
+```
+
+You might want to pass some information about the upstream pipeline using, for
+example, predefined variables. In order to do that, you can use interpolation
+to pass any variable. For example:
+
+```yaml
+downstream-job:
+  variables:
+    UPSTREAM_BRANCH: $CI_COMMIT_REF_NAME
+  trigger: my/project
+```
+
+In this scenario, the `UPSTREAM_BRANCH` variable with a value related to the
+upstream pipeline is passed to the `downstream-job` job. It is available
+in the context of all downstream builds.
+
+Upstream pipelines take precedence over downstream ones. If there are two
+variables with the same name defined in both upstream and downstream projects,
+the ones defined in the upstream project take precedence.
+
+#### Pass CI/CD variables to a downstream pipeline by using variable inheritance
+
+You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](../variables/index.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](../yaml/index.md#cross-project-artifact-downloads-with-needs).
+
+In the upstream pipeline:
+
+1. Save the variables in a `.env` file.
+1. Save the `.env` file as a `dotenv` report.
+1. Trigger the downstream pipeline.
+
+   ```yaml
+   build_vars:
+     stage: build
+     script:
+       - echo "BUILD_VERSION=hello" >> build.env
+     artifacts:
+       reports:
+         dotenv: build.env
+
+   deploy:
+     stage: deploy
+     trigger: my/downstream_project
+   ```
+
+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
+   `dotenv` report and it can access `BUILD_VERSION` in the script:
+
+   ```yaml
+   test:
+     stage: test
+     script:
+       - echo $BUILD_VERSION
+     needs:
+       - project: my/upstream_project
+         job: build_vars
+         ref: master
+         artifacts: true
+   ```
+
+#### Use `rules` or `only`/`except` with multi-project pipelines
+
+You can use CI/CD variables or the [`rules`](../yaml/index.md#rulesif) keyword to
+[control job behavior](../jobs/job_control.md) for multi-project pipelines. When a
+downstream pipeline is triggered with the [`trigger`](../yaml/index.md#trigger) keyword,
+the value of the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md)
+is `pipeline` for all its jobs.
+
+If you use [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
+[`pipelines`](../yaml/index.md#onlyrefs--exceptrefs) keyword.
+
+#### Mirror status of a triggered pipeline in the trigger job
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11238) in GitLab Premium 12.3.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
+
+You can mirror the pipeline status from the triggered pipeline to the source
+trigger job by using `strategy: depend`. For example:
+
+```yaml
+trigger_job:
+  trigger:
+    project: my/project
+    strategy: depend
+```
+
+#### Mirror status from upstream pipeline
+
+You can mirror the pipeline status from an upstream pipeline to a bridge job by
+using the `needs:pipeline` keyword. The latest pipeline status from the default branch is
+replicated to the bridge job.
+
+For example:
+
+```yaml
+upstream_bridge:
+  stage: test
+  needs:
+    pipeline: other/project
+```
+
+### Create multi-project pipelines by using the API
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.
+
+When you use the [`CI_JOB_TOKEN` to trigger pipelines](../triggers/index.md#ci-job-token),
+GitLab recognizes the source of the job token. The pipelines become related,
+so you can visualize their relationships on pipeline graphs.
+
+These relationships are displayed in the pipeline graph by showing inbound and
+outbound connections for upstream and downstream pipeline dependencies.
+
+When using:
+
+- CI/CD variables or [`rules`](../yaml/index.md#rulesif) to control job behavior, the value of
+  the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md) is
+  `pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
+- [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
+  `pipelines` keyword.
+
+## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9045) in GitLab Premium 12.8.
+
+You can trigger a pipeline in your project whenever a pipeline finishes for a new
+tag in a different project.
+
+Prerequisites:
+
+- The upstream project must be [public](../../public_access/public_access.md).
+- The user must have the [Developer role](../../user/permissions.md#project-members-permissions)
+  in the upstream project.
+
+To trigger the pipeline when the upstream project is rebuilt:
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > CI/CD** page.
+1. Expand the **Pipeline subscriptions** section.
+1. Enter the project you want to subscribe to, in the format `<namespace>/<project>`.
+   For example, if the project is `https://gitlab.com/gitlab-org/gitlab`, use `gitlab-org/gitlab`.
+1. Select **Subscribe**.
+
+Any pipelines that complete successfully for new tags in the subscribed project
+now trigger a pipeline on the current project's default branch. The maximum
+number of upstream pipeline subscriptions is 2 by default, for both the upstream and
+downstream projects. On self-managed instances, an administrator can change this
+[limit](../../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project).
+
+## Multi-project pipeline visualization **(PREMIUM)**
+
+When you configure GitLab CI/CD for your project, you can visualize the stages of your
+[jobs](index.md#configure-a-pipeline) on a [pipeline graph](index.md#visualize-pipelines).
+
+![Multi-project pipeline graph](img/multi_project_pipeline_graph.png)
+
+In the merge request, on the **Pipelines** tab, multi-project pipeline mini-graphs are displayed.
+They expand and are shown adjacent to each other when hovering (or tapping on touchscreen devices).
+
+![Multi-project mini graph](img/multi_pipeline_mini_graph.gif)
diff --git a/doc/ci/pipelines/parent_child_pipelines.md b/doc/ci/pipelines/parent_child_pipelines.md
new file mode 100644
index 00000000000..2e29f4fe812
--- /dev/null
+++ b/doc/ci/pipelines/parent_child_pipelines.md
@@ -0,0 +1,192 @@
+---
+stage: Verify
+group: Pipeline Authoring
+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
+type: reference
+---
+
+# Parent-child pipelines **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) in GitLab 12.7.
+
+As pipelines grow more complex, a few related problems start to emerge:
+
+- The staged structure, where all steps in a stage must be completed before the first
+  job in next stage begins, causes arbitrary waits, slowing things down.
+- Configuration for the single global pipeline becomes very long and complicated,
+  making it hard to manage.
+- Imports with [`include`](../yaml/index.md#include) increase the complexity of the configuration, and create the potential
+  for namespace collisions where jobs are unintentionally duplicated.
+- Pipeline UX can become unwieldy with so many jobs and stages to work with.
+
+Additionally, sometimes the behavior of a pipeline needs to be more dynamic. The ability
+to choose to start sub-pipelines (or not) is a powerful ability, especially if the
+YAML is dynamically generated.
+
+![Parent pipeline graph expanded](img/parent_pipeline_graph_expanded_v12_6.png)
+
+Similarly to [multi-project pipelines](multi_project_pipelines.md), a pipeline can trigger a
+set of concurrently running child pipelines, but within the same project:
+
+- Child pipelines still execute each of their jobs according to a stage sequence, but
+  would be free to continue forward through their stages without waiting for unrelated
+  jobs in the parent pipeline to finish.
+- The configuration is split up into smaller child pipeline configurations, which are
+  easier to understand. This reduces the cognitive load to understand the overall configuration.
+- Imports are done at the child pipeline level, reducing the likelihood of collisions.
+- Each pipeline has only relevant steps, making it easier to understand what's going on.
+
+Child pipelines work well with other GitLab CI/CD features:
+
+- Use [`rules: changes`](../yaml/index.md#ruleschanges) to trigger pipelines only when
+  certain files change. This is useful for monorepos, for example.
+- 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
+include the child pipeline configuration.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For an overview, see [Parent-Child Pipelines feature demo](https://youtu.be/n8KpBSqZNbk).
+
+## Examples
+
+The simplest case is [triggering a child pipeline](../yaml/index.md#trigger) using a
+local YAML file to define the pipeline configuration. In this case, the parent pipeline
+triggers the child pipeline, and continues without waiting:
+
+```yaml
+microservice_a:
+  trigger:
+    include: path/to/microservice_a.yml
+```
+
+You can include multiple files when composing a child pipeline:
+
+```yaml
+microservice_a:
+  trigger:
+    include:
+      - local: path/to/microservice_a.yml
+      - template: Security/SAST.gitlab-ci.yml
+```
+
+In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) and later,
+you can use [`include:file`](../yaml/index.md#includefile) to trigger child pipelines
+with a configuration file in a different project:
+
+```yaml
+microservice_a:
+  trigger:
+    include:
+      - project: 'my-group/my-pipeline-library'
+        file: 'path/to/ci-config.yml'
+```
+
+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:
+
+```yaml
+microservice_a:
+  trigger:
+    include:
+      - local: path/to/microservice_a.yml
+      - template: Security/SAST.gitlab-ci.yml
+    strategy: depend
+```
+
+## Merge Request child pipelines
+
+To trigger a child pipeline as a [Merge Request Pipeline](merge_request_pipelines.md) we need to:
+
+- Set the trigger job to run on merge requests:
+
+```yaml
+# parent .gitlab-ci.yml
+microservice_a:
+  trigger:
+    include: path/to/microservice_a.yml
+  rules:
+    - if: $CI_MERGE_REQUEST_ID
+```
+
+- Configure the child pipeline by either:
+
+  - Setting all jobs in the child pipeline to evaluate in the context of a merge request:
+
+    ```yaml
+    # child path/to/microservice_a.yml
+    workflow:
+      rules:
+        - if: $CI_MERGE_REQUEST_ID
+
+    job1:
+      script: ...
+
+    job2:
+      script: ...
+    ```
+
+  - Alternatively, setting the rule per job. For example, to create only `job1` in
+    the context of merge request pipelines:
+
+    ```yaml
+    # child path/to/microservice_a.yml
+    job1:
+      script: ...
+      rules:
+        - if: $CI_MERGE_REQUEST_ID
+
+    job2:
+      script: ...
+    ```
+
+## Dynamic child pipelines
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) in GitLab 12.9.
+
+Instead of running a child pipeline from a static YAML file, you can define a job that runs
+your own script to generate a YAML file, which is then [used to trigger a child pipeline](../yaml/index.md#trigger-child-pipeline-with-generated-configuration-file).
+
+This technique can be very powerful in generating pipelines targeting content that changed or to
+build a matrix of targets and architectures.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For an overview, see [Create child pipelines using dynamically generated configurations](https://youtu.be/nMdfus2JWHM).
+
+<!-- vale gitlab.Spelling = NO -->
+We also have an example project using
+[Dynamic Child Pipelines with Jsonnet](https://gitlab.com/gitlab-org/project-templates/jsonnet)
+which shows how to use a data templating language to generate your `.gitlab-ci.yml` at runtime. You could use a similar process for other templating languages like [Dhall](https://dhall-lang.org/) or [`ytt`](https://get-ytt.io/).
+<!-- vale gitlab.Spelling = NO -->
+
+The artifact path is parsed by GitLab, not the runner, so the path must match the
+syntax for the OS running GitLab. If GitLab is running on Linux but using a Windows
+runner for testing, the path separator for the trigger job would be `/`. Other CI/CD
+configuration for jobs, like scripts, that use the Windows runner would use `\`.
+
+In GitLab 12.9, the child pipeline could fail to be created in certain cases, causing the parent pipeline to fail.
+This is [resolved in GitLab 12.10](https://gitlab.com/gitlab-org/gitlab/-/issues/209070).
+
+## Nested child pipelines
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29651) in GitLab 13.4.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243747) in GitLab 13.5.
+
+Parent and child pipelines were introduced with a maximum depth of one level of child
+pipelines, which was later increased to two. A parent pipeline can trigger many child
+pipelines, and these child pipelines can trigger their own child pipelines. It's not
+possible to trigger another level of child pipelines.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For an overview, see [Nested Dynamic Pipelines](https://youtu.be/C5j3ju9je2M).
+
+## Pass CI/CD variables to a child pipeline
+
+You can pass CI/CD variables to a downstream pipeline using the same methods as
+multi-project pipelines:
+
+- [By using the `variable` keyword](multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword).
+- [By using variable inheritance](multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-variable-inheritance).
diff --git a/doc/ci/pipelines/pipeline_architectures.md b/doc/ci/pipelines/pipeline_architectures.md
index 184bc5a956a..1b23727b142 100644
--- a/doc/ci/pipelines/pipeline_architectures.md
+++ b/doc/ci/pipelines/pipeline_architectures.md
@@ -162,7 +162,7 @@ deploy_b:
 ## Child / Parent Pipelines
 
 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
+This is an ideal case for using [Child / Parent Pipelines](parent_child_pipelines.md)) via
 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:
 
diff --git a/doc/ci/pipelines/pipeline_efficiency.md b/doc/ci/pipelines/pipeline_efficiency.md
index 5d8d4fa8ff1..91560a0420f 100644
--- a/doc/ci/pipelines/pipeline_efficiency.md
+++ b/doc/ci/pipelines/pipeline_efficiency.md
@@ -186,7 +186,7 @@ shouldn't run, saving pipeline resources.
 In a basic configuration, jobs always wait for all other jobs in earlier stages to complete
 before running. This is the simplest configuration, but it's also the slowest in most
 cases. [Directed Acyclic Graphs](../directed_acyclic_graph/index.md) and
-[parent/child pipelines](../parent_child_pipelines.md) are more flexible and can
+[parent/child pipelines](parent_child_pipelines.md) are more flexible and can
 be more efficient, but can also make pipelines harder to understand and analyze.
 
 ### Caching