Find and replace mr pipeline naming

We are renaming pipelines for merge requests
and merged results as 'merge request pipelines'
and 'merged results pipelines'. This MR finds and
replaces all of these as needed.

doc/administration/instance_limits.md

@@ -214,7 +214,7 @@ or `git push --mirror` is used.
 
 This limit does not affect any of the updated merge request pipelines.
 All updated merge requests have a pipeline created when using
-[pipelines for merge requests](../ci/pipelines/merge_request_pipelines.md).
+[merge request pipelines](../ci/pipelines/merge_request_pipelines.md).
 
 ## Retention of activity history
 

doc/api/merge_requests.md

@@ -1041,7 +1041,7 @@ The new pipeline can be:
 
 - A detached merge request pipeline.
 - A [pipeline for merged results](../ci/pipelines/pipelines_for_merged_results.md)
-  if the [project setting is enabled](../ci/pipelines/pipelines_for_merged_results.md#enable-pipelines-for-merged-results). **(PREMIUM)**
+  if the [project setting is enabled](../ci/pipelines/pipelines_for_merged_results.md#enable-merged-results-pipelines).
 
 ```plaintext
 POST /projects/:id/merge_requests/:merge_request_iid/pipelines

doc/ci/environments/index.md

@@ -308,7 +308,7 @@ Note the following:
 - If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update
   the environment URL.
 - If the script that runs in `stop_review` exists only in your repository and therefore can't use
-  `GIT_STRATEGY: none`, configure [pipelines for merge requests](../../ci/pipelines/merge_request_pipelines.md)
+  `GIT_STRATEGY: none`, configure [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md)
   for these jobs. This ensures that runners can fetch the repository even after a feature branch is
   deleted. For more information, see [Ref Specs for Runners](../pipelines/index.md#ref-specs-for-runners).
 
@@ -440,7 +440,7 @@ the `stop_review` job might not be included in all pipelines that include the
 The job with [`action: stop` might not run](#the-job-with-action-stop-doesnt-run)
 if it's in a later stage than the job that started the environment.
 
-If you can't use [pipelines for merge requests](../pipelines/merge_request_pipelines.md),
+If you can't use [merge request pipelines](../pipelines/merge_request_pipelines.md),
 set the [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy) to `none` in the
 `stop_review` job. Then the [runner](https://docs.gitlab.com/runner/) doesn't
 try to check out the code after the branch is deleted.

doc/ci/index.md

@@ -64,7 +64,7 @@ GitLab CI/CD supports numerous configuration options:
 | [Git submodules for CI/CD](git_submodules.md)                                           | Configure jobs for using Git submodules.                                                  |
 | [SSH keys for CI/CD](ssh_keys/index.md)                                                 | Using SSH keys in your CI pipelines.                                                      |
 | [Pipeline triggers](triggers/index.md)                                                  | Trigger pipelines through the API.                                                        |
-| [Pipelines for merge requests](pipelines/merge_request_pipelines.md)                    | Design a pipeline structure for running a pipeline in merge requests.                     |
+| [Merge request pipelines](pipelines/merge_request_pipelines.md)                    | Design a pipeline structure for running a pipeline in merge requests.                     |
 | [Integrate with Kubernetes clusters](../user/infrastructure/clusters/index.md)                 | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. |
 | [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories.                                   |
 | [`.gitlab-ci.yml` full reference](yaml/index.md)                                        | All the attributes you can use with GitLab CI/CD.                                         |

doc/ci/jobs/job_control.md

@@ -406,9 +406,9 @@ the `build` job is still skipped. The job does not run for any of the files.
 
 With some configurations that use `changes`, [jobs or pipelines might run unexpectedly](#jobs-or-pipelines-run-unexpectedly-when-using-changes)
 
-#### Use `only:changes` with pipelines for merge requests
+#### Use `only:changes` with merge request pipelines
 
-With [pipelines for merge requests](../pipelines/merge_request_pipelines.md),
+With [merge request pipelines](../pipelines/merge_request_pipelines.md),
 it's possible to define a job to be created based on files modified
 in a merge request.
 
@@ -931,7 +931,7 @@ For example:
 
 You might have jobs or pipelines that run unexpectedly when using [`rules: changes`](../yaml/index.md#ruleschanges)
 or [`only: changes`](../yaml/index.md#onlychanges--exceptchanges) without
-[pipelines for merge requests](../pipelines/merge_request_pipelines.md).
+[merge request pipelines](../pipelines/merge_request_pipelines.md).
 
 Pipelines on branches or tags that don't have an explicit association with a merge request
 use a previous SHA to calculate the diff. This calculation is equivalent to `git diff HEAD~`

doc/ci/pipelines/index.md

@@ -50,13 +50,13 @@ 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.
-- [Pipelines for merge requests](../pipelines/merge_request_pipelines.md) run for merge
+- [Merge request pipelines](../pipelines/merge_request_pipelines.md) run for merge
   requests only (rather than for every commit).
-- [Pipelines for merged results](../pipelines/pipelines_for_merged_results.md)
+- [Merged results pipelines](../pipelines/pipelines_for_merged_results.md)
   are merge request pipelines that act as though the changes from the source branch have
   already been merged into the target branch.
 - [Merge trains](../pipelines/merge_trains.md)
-  use pipelines for merged results to queue merges one after the other.
+  use merged results pipelines to queue merges one after the other.
 - [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. This pipeline architecture is commonly used for mono-repos.
@@ -123,7 +123,7 @@ This table lists the refspecs injected for each pipeline type:
 |---------------                                                     |----------------------------------------                                                        |
 | pipeline for branches                                              | `+<sha>:refs/pipelines/<id>` and `+refs/heads/<name>:refs/remotes/origin/<name>` |
 | pipeline for tags                                                  | `+<sha>:refs/pipelines/<id>` and `+refs/tags/<name>:refs/tags/<name>`            |
-| [pipeline for merge requests](../pipelines/merge_request_pipelines.md) | `+<sha>:refs/pipelines/<id>`                                                     |
+| [merge request pipeline](../pipelines/merge_request_pipelines.md) | `+<sha>:refs/pipelines/<id>`                                                     |
 
 The refs `refs/heads/<name>` and `refs/tags/<name>` exist in your
 project repository. GitLab generates the special ref `refs/pipelines/<id>` during a

doc/ci/pipelines/merge_request_pipelines.md

@@ -5,13 +5,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ---
 
 
-# Pipelines for merge requests **(FREE)**
+# Merge request pipelines **(FREE)**
 
 You can configure your [pipeline](index.md) to run every time you commit changes to a branch.
 This type of pipeline is called a *branch pipeline*.
 
 Alternatively, you can configure your pipeline to run every time you make changes to the
-source branch for a merge request. This type of pipeline is called a *pipeline for merge requests*.
+source branch for a merge request. This type of pipeline is called a *merge request pipeline*.
 
 Branch pipelines:
 
@@ -20,28 +20,28 @@ Branch pipelines:
 - Have access to [some predefined variables](../variables/predefined_variables.md).
 - Have access to [protected variables](../variables/index.md#protect-a-cicd-variable).
 
-Pipelines for merge requests:
+Merge request pipelines:
 
 - Run when you:
   - Create a new merge request.
   - Push a new commit to the source branch for a merge request.
   - Select **Run pipeline** from the **Pipelines** tab in a merge request. This option
-    is only available when pipelines for merge requests are configured for the pipeline.
+    is only available when merge request pipelines are configured for the pipeline.
 - Do not run by default. The jobs in the CI/CD configuration file [must be configured](#prerequisites)
-  to run in pipelines for merge request.
+  to run in merge request pipelines.
 - Have access to [more predefined variables](#available-predefined-variables).
 - Do not have access to [protected variables](../variables/index.md#protect-a-cicd-variable).
 
 Both of these types of pipelines can appear on the **Pipelines** tab of a merge request.
 
-## Types of pipelines for merge requests
+## Types of merge request pipelines
 
-The three types of pipelines for merge requests are:
+The three types of merge request pipelines are:
 
-- Pipelines for merge requests, which run on the changes in the merge request's
+- Merge request pipelines, which run on the changes in the merge request's
   source branch. These pipelines display a `detached` label to indicate that the
   pipeline ran only on the contents of the source branch, ignoring the target branch.
-- [Pipelines for merged results](pipelines_for_merged_results.md), which run on
+- [Merged results pipelines](pipelines_for_merged_results.md), which run on
   the result of combining the source branch's changes with the target branch.
 - [Merge trains](merge_trains.md), which run when merging multiple merge requests
   at the same time. The changes from each merge request are combined into the
@@ -50,31 +50,31 @@ The three types of pipelines for merge requests are:
 
 ## Prerequisites
 
-To use pipelines for merge requests:
+To use merge request pipelines:
 
 - Your project's [CI/CD configuration file](../yaml/index.md) must be configured with
-  jobs that run in pipelines for merge requests. To do this, you can use:
+  jobs that run in merge request pipelines. To do this, you can use:
   - [`rules`](#use-rules-to-add-jobs).
   - [`only/except`](#use-only-to-add-jobs).
 - You must have at least the Developer [role](../../user/permissions.md) in the
-  source project to run a pipeline for merge requests.
+  source project to run a merge request pipeline.
 - Your repository must be a GitLab repository, not an [external repository](../ci_cd_for_external_repos/index.md).
 
 ## Use `rules` to add jobs
 
 You can use the [`rules`](../yaml/index.md#rules) keyword to configure jobs to run in
-pipelines for merge requests. For example:
+merge request pipelines. For example:
 
 ```yaml
 job1:
   script:
-    - echo "This job runs in pipelines for merge requests"
+    - echo "This job runs in merge request pipelines"
   rules:
     - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
 ```
 
 You can also use the [`workflow: rules`](../yaml/index.md#workflowrules) keyword
-to configure the entire pipeline to run in pipelines for merge requests. For example:
+to configure the entire pipeline to run in merge request pipelines. For example:
 
 ```yaml
 workflow:
@@ -83,22 +83,22 @@ workflow:
 
 job1:
   script:
-    - echo "This job runs in pipelines for merge requests"
+    - echo "This job runs in merge request pipelines"
 
 job2:
   script:
-    - echo "This job also runs in pipelines for merge requests"
+    - echo "This job also runs in merge request pipelines"
 ```
 
 ## Use `only` to add jobs
 
 You can use the [`only`](../yaml/index.md#onlyrefs--exceptrefs) keyword with `merge_requests`
-to configure jobs to run in pipelines for merge requests.
+to configure jobs to run in merge request pipelines.
 
 ```yaml
 job1:
   script:
-    - echo "This job runs in pipelines for merge requests"
+    - echo "This job runs in merge request pipelines"
   only:
     - merge_requests
 ```
@@ -122,7 +122,7 @@ Pipelines for forks display with the **fork** badge in the parent project:
 
 ### Run pipelines in the parent project **(PREMIUM)**
 
-Project members in the parent project can choose to run a pipeline for merge requests
+Project members in the parent project can choose to run a merge request pipeline
 for a merge request submitted from a fork project. This pipeline:
 
 - Is created and runs in the parent (target) project, not the fork (source) project.
@@ -148,12 +148,12 @@ can create pipelines in the parent project for merge requests from a forked proj
 
 ## Available predefined variables
 
-When you use pipelines for merge requests, you can use:
+When you use merge request pipelines, you can use:
 
 - All the same [predefined variables](../variables/predefined_variables.md) that are
   available in branch pipelines.
 - [Additional predefined variables](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines)
-  available only to jobs in pipelines for merge requests. These variables contain
+  available only to jobs in merge request pipelines. These variables contain
   information from the associated merge request, which can be when calling the
   [GitLab Merge Request API endpoint](../../api/merge_requests.md) from a job.
 
@@ -166,14 +166,14 @@ to run for both branches and merge requests at the same time. Adjust your pipeli
 configuration to [avoid duplicate pipelines](../jobs/job_control.md#avoid-duplicate-pipelines).
 
 In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201845),
-you can add `workflow:rules` to [switch from branch pipelines to pipelines for merge requests](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines).
+you can add `workflow:rules` to [switch from branch pipelines to merge request pipelines](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines).
 After a merge request is open on the branch, the pipeline switches to a merge request pipeline.
 
 ### Two pipelines when pushing an invalid CI/CD configuration file
 
 If you push an invalid CI/CD configuration to a merge request's branch, two failed
 pipelines appear in the pipelines tab. One pipeline is a failed branch pipeline,
-the other is a failed pipeline for merge requests.
+the other is a failed merge request pipeline.
 
 When the configuration syntax is fixed, no further failed pipelines should appear.
 To find and fix the configuration problem, you can use:
@@ -183,7 +183,7 @@ To find and fix the configuration problem, you can use:
 
 ### The merge request's pipeline is marked as failed but the latest pipeline succeeded
 
-It's possible to have both branch pipelines and pipelines for merge requests in the
+It's possible to have both branch pipelines and merge request pipelines in the
 **Pipelines** tab of a single merge request. This might be [by configuration](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines),
 or [by accident](#two-pipelines-when-pushing-to-a-branch).
 
@@ -194,5 +194,5 @@ is not considered successful if:
 - The pipeline for merge request fails.
 
 When using the [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
-feature and both pipelines types are present, the pipelines for merge requests are checked,
+feature and both pipelines types are present, the merge request pipelines are checked,
 not the branch pipelines.

doc/ci/pipelines/merge_trains.md

@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 For more information about why you might want to use merge trains, read [How merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
 
-When [pipelines for merged results](pipelines_for_merged_results.md) are
+When [merged results pipelines](pipelines_for_merged_results.md) are
 enabled, the pipeline jobs run as if the changes from your source branch have already
 been merged into the target branch.
 
@@ -93,7 +93,7 @@ In GitLab 13.5 and earlier, there is only one checkbox, named
 
 WARNING:
 If you select the check box but don't configure your CI/CD to use
-pipelines for merge requests, your merge requests may become stuck in an
+merge request pipelines, your merge requests may become stuck in an
 unresolved state or your pipelines may be dropped.
 
 ## Start a merge train
@@ -229,8 +229,8 @@ In [GitLab 13.6 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/244831)
 you can [enable or disable merge trains in the project settings](#enable-merge-trains).
 
 In GitLab 13.5 and earlier, merge trains are automatically enabled when
-[pipelines for merged results](pipelines_for_merged_results.md) are enabled.
-To use pipelines for merged results without using merge trains, you can enable a
+[merged results pipelines](pipelines_for_merged_results.md) are enabled.
+To use merged results pipelines without using merge trains, you can enable a
 [feature flag](../../user/feature_flags.md) that blocks the merge trains feature.
 
 [GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md)

doc/ci/pipelines/pipelines_for_merged_results.md

@@ -4,9 +4,9 @@ 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
 ---
 
-# Pipelines for merged results **(PREMIUM)**
+# Merged results pipelines **(PREMIUM)**
 
-A *pipeline for merged results* is a type of [pipeline for merge requests](merge_request_pipelines.md). It is a pipeline that runs against the results of the source and target branches merged together.
+A *pipeline for merged results* is a type of [merge request pipeline](merge_request_pipelines.md). It is a pipeline that runs against the results of the source and target branches merged together.
 
 GitLab creates an internal commit with the merged results, so the pipeline can run
 against it. This commit does not exist in either branch,
@@ -16,28 +16,28 @@ The pipeline runs against the target branch as it exists at the moment you run t
 Over time, while you're working in the source branch, the target branch might change.
 Any time you want to be sure the merged results are accurate, you should re-run the pipeline.
 
-Pipelines for merged results can't run when:
+Merged results pipelines can't run when:
 
 - The target branch has changes that conflict with the changes in the source branch.
 - The merge request is a [**Draft** merge request](../../user/project/merge_requests/drafts.md).
 
-In these cases, the pipeline runs as a [pipeline for merge requests](merge_request_pipelines.md)
+In these cases, the pipeline runs as a [merge request pipeline](merge_request_pipelines.md)
 and is labeled as `detached`.
 
 ## Prerequisites
 
-To use pipelines for merged results:
+To use merged results pipelines:
 
 - Your project's [CI/CD configuration file](../yaml/index.md) must be configured to
-  [run jobs in pipelines for merge requests](merge_request_pipelines.md#prerequisites).
+  [run jobs in merge request pipelines](merge_request_pipelines.md#prerequisites).
 - Your repository must be a GitLab repository, not an
   [external repository](../ci_cd_for_external_repos/index.md).
 - You must not be using [fast forward merges](../../user/project/merge_requests/fast_forward_merge.md).
   [An issue exits](https://gitlab.com/gitlab-org/gitlab/-/issues/26996) to change this behavior.
 
-## Enable pipelines for merged results
+## Enable merged results pipelines
 
-To enable pipelines for merged results in a project, you must have at least the
+To enable merged results pipelines in a project, you must have at least the
 [Maintainer role](../../user/permissions.md):
 
 1. On the top bar, select **Menu > Projects** and find your project.
@@ -48,14 +48,14 @@ To enable pipelines for merged results in a project, you must have at least the
 
 WARNING:
 If you select the checkbox but don't configure your pipeline to use
-pipelines for merge requests, your merge requests may become stuck in an
+merge request pipelines, your merge requests may become stuck in an
 unresolved state or your pipelines may be dropped.
 
 ## Troubleshooting
 
-### Pipelines for merged results are not created
+### Merged results pipelines are not created
 
-In GitLab 13.7 and earlier, pipelines for merged results might not be created due
+In GitLab 13.7 and earlier, merged results pipelines might not be created due
 to a disabled [feature flag](../../user/feature_flags.md). This feature flag
 [was removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299115) in GitLab 13.8.
 Upgrade to 13.8 or later, or make sure the `:merge_ref_auto_sync`
@@ -64,7 +64,7 @@ on your GitLab instance.
 
 ### Pipelines fail intermittently with a `fatal: reference is not a tree:` error
 
-Pipelines for merged results run on a merge ref for a merge request
+Merged results pipelines run on a merge ref for a merge request
 (`refs/merge-requests/<iid>/merge`), so the Git reference could be overwritten at an
 unexpected time.
 

doc/ci/troubleshooting.md

@@ -69,12 +69,12 @@ if you are using that type:
   and run separate pipelines in the same project. You can also
   [dynamically generate the child pipeline's configuration](pipelines/parent_child_pipelines.md#dynamic-child-pipelines)
   at runtime.
-- [Pipelines for merge requests](pipelines/merge_request_pipelines.md): Run a pipeline
+- [Merge request pipelines](pipelines/merge_request_pipelines.md): Run a pipeline
   in the context of a merge request.
   - [Pipelines for merge results](pipelines/pipelines_for_merged_results.md):
-    Pipelines for merge requests that run on the combined source and target branch
+    Merge request pipelines that run on the combined source and target branch
   - [Merge trains](pipelines/merge_trains.md):
-    Multiple pipelines for merged results that queue and run automatically before
+    Multiple merged results pipelines that queue and run automatically before
     changes are merged.
 
 ### Troubleshooting Guides for CI/CD features
@@ -173,7 +173,7 @@ a branch to its remote repository. To illustrate the problem, suppose you've had
 
 This occurs because the previous pipeline cannot find a checkout-SHA (which is associated with the pipeline record)
 from the `example` branch that the commit history has already been overwritten by the force-push.
-Similarly, [Pipelines for merged results](pipelines/pipelines_for_merged_results.md)
+Similarly, [Merged results pipelines](pipelines/pipelines_for_merged_results.md)
 might have failed intermittently due to [the same reason](pipelines/pipelines_for_merged_results.md#pipelines-fail-intermittently-with-a-fatal-reference-is-not-a-tree-error).
 
 As of GitLab 12.4, we've improved this behavior by persisting pipeline refs exclusively.

doc/ci/variables/index.md

@@ -372,7 +372,7 @@ You can protect a project, group or instance CI/CD variable so it is only passed
 to pipelines running on [protected branches](../../user/project/protected_branches.md)
 or [protected tags](../../user/project/protected_tags.md).
 
-[Pipelines for merge requests](../pipelines/merge_request_pipelines.md) do not have access to protected variables.
+[Merge request pipelines](../pipelines/merge_request_pipelines.md) do not have access to protected variables.
 An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/28002) regarding this limitation.
 
 To protect a variable:

doc/ci/variables/predefined_variables.md

@@ -27,7 +27,7 @@ There are also a number of [variables you can use to configure runner behavior](
 | `CI_API_V4_URL`                          | 11.7   | all    | The GitLab API v4 root URL. |
 | `CI_BUILDS_DIR`                          | all    | 11.10  | The top-level directory where builds are executed. |
 | `CI_COMMIT_AUTHOR`                       | 13.11  | all    | The author of the commit in `Name <email>` format. |
-| `CI_COMMIT_BEFORE_SHA`                   | 11.2   | all    | The previous latest commit present on a branch. Is always `0000000000000000000000000000000000000000` in pipelines for merge requests. |
+| `CI_COMMIT_BEFORE_SHA`                   | 11.2   | all    | The previous latest commit present on a branch. Is always `0000000000000000000000000000000000000000` in merge request pipelines. |
 | `CI_COMMIT_BRANCH`                       | 12.6   | 0.5    | The commit branch name. Available in branch pipelines, including pipelines for the default branch. Not available in merge request pipelines or tag pipelines. |
 | `CI_COMMIT_DESCRIPTION`                  | 10.8   | all    | The description of the commit. If the title is shorter than 100 characters, the message without the first line. |
 | `CI_COMMIT_MESSAGE`                      | 10.8   | all    | The full commit message. |

doc/ci/yaml/index.md

@@ -415,7 +415,7 @@ and the pipeline is for either:
 - You can use the [`workflow:rules` templates](workflow.md#workflowrules-templates) to import
   a preconfigured `workflow: rules` entry.
 - [Common `if` clauses for `workflow:rules`](workflow.md#common-if-clauses-for-workflowrules).
-- [Use `rules` to run pipelines for merge requests](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
+- [Use `rules` to run merge request pipelines](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
 
 #### `workflow:rules:variables`
 
@@ -2471,7 +2471,7 @@ Use `changes` in pipelines with the following refs:
 
 - `branches`
 - `external_pull_requests`
-- `merge_requests` (see additional details about [using `only:changes` with pipelines for merge requests](../jobs/job_control.md#use-onlychanges-with-pipelines-for-merge-requests))
+- `merge_requests` (see additional details about [using `only:changes` with merge request pipelines](../jobs/job_control.md#use-onlychanges-with-merge-request-pipelines))
 
 **Keyword type**: Job keyword. You can use it only as part of a job.
 
@@ -2513,7 +2513,7 @@ docker build:
 
 - [`only: changes` and `except: changes` examples](../jobs/job_control.md#onlychanges--exceptchanges-examples).
 - If you use `changes` with [only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds),
-  you should [also use `only:merge_requests`](../jobs/job_control.md#use-onlychanges-with-pipelines-for-merge-requests).
+  you should [also use `only:merge_requests`](../jobs/job_control.md#use-onlychanges-with-merge-request-pipelines).
 - [Jobs or pipelines can run unexpectedly when using `only: changes`](../jobs/job_control.md#jobs-or-pipelines-run-unexpectedly-when-using-changes).
 
 #### `only:kubernetes` / `except:kubernetes`
@@ -3085,7 +3085,7 @@ job:
 
 - [Common `if` expressions for `rules`](../jobs/job_control.md#common-if-clauses-for-rules).
 - [Avoid duplicate pipelines](../jobs/job_control.md#avoid-duplicate-pipelines).
-- [Use `rules` to run pipelines for merge requests](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
+- [Use `rules` to run merge request pipelines](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
 
 #### `rules:changes`
 

doc/ci/yaml/workflow.md

@@ -126,7 +126,7 @@ makes your pipelines run for branches and tags.
 Branch pipeline status is displayed in merge requests that use the branch
 as a source. However, this pipeline type does not support any features offered by
 [merge request pipelines](../pipelines/merge_request_pipelines.md), like
-[pipelines for merged results](../pipelines/pipelines_for_merged_results.md)
+[merged results pipelines](../pipelines/pipelines_for_merged_results.md)
 or [merge trains](../pipelines/merge_trains.md).
 This template intentionally avoids those features.
 
@@ -140,7 +140,7 @@ include:
 The [`MergeRequest-Pipelines` template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Workflows/MergeRequest-Pipelines.gitlab-ci.yml)
 makes your pipelines run for the default branch, tags, and
 all types of merge request pipelines. Use this template if you use any of the
-the [pipelines for merge requests features](../pipelines/merge_request_pipelines.md).
+the [merge request pipelines features](../pipelines/merge_request_pipelines.md).
 
 To [include](index.md#include) it:
 

doc/development/cicd/index.md

@@ -27,7 +27,7 @@ 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/pipelines/merge_request_pipelines.md#pipelines-for-merge-requests).
+- When a [merge request is created or updated](../../ci/pipelines/merge_request_pipelines.md).
 - 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/pipelines/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt).

doc/development/documentation/review_apps.md

@@ -61,7 +61,7 @@ The following GitLab features are used among others:
 - [Review Apps](../../ci/review_apps/index.md)
 - [Artifacts](../../ci/yaml/index.md#artifacts)
 - [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
-- [Pipelines for merge requests](../../ci/pipelines/merge_request_pipelines.md)
+- [Merge request pipelines](../../ci/pipelines/merge_request_pipelines.md)
 
 ## Troubleshooting review apps
 

doc/development/testing_guide/end_to_end/index.md

@@ -126,7 +126,7 @@ A --> C
 B --> C
 
 A --> E["E2E tests"]
-C --> D["Pipeline for merged results"]
+C --> D["Merged results pipeline"]
  ```
 
 ##### Running custom tests

doc/user/application_security/index.md

@@ -101,7 +101,7 @@ the container-scanning analyzer which uses
 ### Use security scanning tools with Pipelines for Merge Requests
 
 By default, the application security jobs are configured to run for branch pipelines only.
-To use them with [pipelines for merge requests](../../ci/pipelines/merge_request_pipelines.md),
+To use them with [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md),
 you may need to override the default `rules:` configuration to add:
 
 ```yaml

doc/user/project/merge_requests/code_quality.md

@@ -248,9 +248,9 @@ This can be done:
 ### Using with merge request pipelines
 
 The configuration provided by the Code Quality template does not let the `code_quality` job
-run on [pipelines for merge requests](../../../ci/pipelines/merge_request_pipelines.md).
+run on [merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md).
 
-If pipelines for merge requests is enabled, the `code_quality:rules` must be redefined.
+If merge request pipelines is enabled, the `code_quality:rules` must be redefined.
 
 The template has these [`rules`](../../../ci/yaml/index.md#rules) for the `code quality` job:
 

doc/user/project/merge_requests/drafts.md

@@ -79,11 +79,11 @@ draft merge requests:
 
 ## Pipelines for drafts
 
-When the [pipelines for merged results](../../../ci/pipelines/pipelines_for_merged_results.md)
+When the [merged results pipelines](../../../ci/pipelines/pipelines_for_merged_results.md)
 feature is enabled, draft merge requests run
 [merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md) only.
 
-To run pipelines for merged results, you must
+To run merged results pipelines, you must
 [mark the merge request as ready](#mark-merge-requests-as-ready).
 
 <!-- ## Troubleshooting

doc/user/project/merge_requests/fail_fast_testing.md

@@ -42,8 +42,8 @@ This template requires:
 - A project built in Rails that uses RSpec for testing.
 - CI/CD configured to:
   - Use a Docker image with Ruby available.
-  - Use [Pipelines for merge requests](../../../ci/pipelines/merge_request_pipelines.md#prerequisites)
-- [Pipelines for Merged Results](../../../ci/pipelines/pipelines_for_merged_results.md#enable-pipelines-for-merged-results)
+  - Use [Merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md#prerequisites)
+- [Pipelines for Merged Results](../../../ci/pipelines/pipelines_for_merged_results.md#enable-merged-results-pipelines)
   enabled in the project settings.
 - A Docker image with Ruby available. The template uses `image: ruby:2.6` by default, but you [can override](../../../ci/yaml/includes.md#override-included-configuration-values) this.
 

doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md

@@ -23,7 +23,7 @@ or link to useful information directly from merge requests:
 | [License Compliance](../../compliance/license_compliance/index.md)               | Manage the licenses of your dependencies.                                                                                                                                                                |
 | [Metrics Reports](../../../ci/metrics_reports.md)                                | Display the Metrics Report on the merge request so that it's fast and easy to identify changes to important metrics.                                                                                     |
 | [Multi-Project pipelines](../../../ci/pipelines/multi_project_pipelines.md)      | When you set up GitLab CI/CD across multiple projects, you can visualize the entire pipeline, including all cross-project interdependencies.                                                             |
-| [Pipelines for merge requests](../../../ci/pipelines/merge_request_pipelines.md) | Customize a specific pipeline structure for merge requests in order to speed the cycle up by running only important jobs.                                                                                |
+| [Merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md) | Customize a specific pipeline structure for merge requests in order to speed the cycle up by running only important jobs.                                                                                |
 | [Pipeline Graphs](../../../ci/pipelines/index.md#visualize-pipelines)            | View the status of pipelines within the merge request, including the deployment process.                                                                                                                 |
 | [Test Coverage visualization](test_coverage_visualization.md)                    | See test coverage results for merge requests, within the file diff.                                                                                                                                      |