Add latest changes from gitlab-org/gitlab@master

12 files changed, 76 insertions, 75 deletions

diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index dfa92d469bc..3f1aea0a4d9 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -38,12 +38,12 @@ runtime dependencies needed to compile the project:
   be configured to pass intermediate build results between stages, this should be
   done with artifacts instead.
 
-- `artifacts`: **Use for stage results that will be passed between stages.**
+- `artifacts`: **Use for stage results that are passed between stages.**
 
   Artifacts are files generated by a job which are stored and uploaded, and can then
   be fetched and used by jobs in later stages of the **same pipeline**. In other words,
   [you can't create an artifact in job-A in stage-1, and then use this artifact in job-B in stage-1](https://gitlab.com/gitlab-org/gitlab/-/issues/25837).
-  This data will not be available in different pipelines, but is available to be downloaded
+  This data is be available in different pipelines, but is available to be downloaded
   from the UI.
 
 The name `artifacts` sounds like it's only useful outside of the job, like for downloading
@@ -87,7 +87,7 @@ cache, when declaring `cache` in your jobs, use one or a mix of the following:
 - [Tag your runners](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
   that share their cache.
 - [Use sticky runners](../runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
-  that will be only available to a particular project.
+  that are only available to a particular project.
 - [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (for example,
   different caches on each branch). For that, you can take advantage of the
   [CI/CD predefined variables](../variables/README.md#predefined-environment-variables).
@@ -106,7 +106,7 @@ of the following must be true:
   where the cache is stored in S3 buckets (like shared runners on GitLab.com).
 - Use multiple runners (not in autoscale mode) of the same architecture that
   share a common network-mounted directory (using NFS or something similar)
-  where the cache will be stored.
+  where the cache is stored.
 
 TIP: **Tip:**
 Read about the [availability of the cache](#availability-of-the-cache)
@@ -125,7 +125,7 @@ cache:
 While this feels like it might be safe from accidentally overwriting the cache,
 it means merge requests get slow first pipelines, which might be a bad
 developer experience. The next time a new commit is pushed to the branch, the
-cache will be re-used.
+cache is re-used.
 
 To enable per-job and per-branch caching:
 
@@ -160,7 +160,7 @@ cache:
 
 ### Disabling cache on specific jobs
 
-If you have defined the cache globally, it means that each job will use the
+If you have defined the cache globally, it means that each job uses the
 same definition. You can override this behavior per-job, and if you want to
 disable it completely, use an empty hash:
 
@@ -431,9 +431,9 @@ Here's what happens behind the scenes:
 1. `script` is executed.
 1. Pipeline finishes.
 
-By using a single runner on a single machine, you'll not have the issue where
+By using a single runner on a single machine, you don't have the issue where
 `job B` might execute on a runner different from `job A`, thus guaranteeing the
-cache between stages. That will only work if the build goes from stage `build`
+cache between stages. That only works if the build goes from stage `build`
 to `test` in the same runner/machine, otherwise, you [might not have the cache
 available](#cache-mismatch).
 
@@ -442,7 +442,7 @@ During the caching process, there's also a couple of things to consider:
 - If some other job, with another cache configuration had saved its
   cache in the same zip file, it is overwritten. If the S3 based shared cache is
   used, the file is additionally uploaded to S3 to an object based on the cache
-  key. So, two jobs with different paths, but the same cache key, will overwrite
+  key. So, two jobs with different paths, but the same cache key, overwrites
   their cache.
 - When extracting the cache from `cache.zip`, everything in the zip file is
   extracted in the job's working directory (usually the repository which is
@@ -450,7 +450,7 @@ During the caching process, there's also a couple of things to consider:
   things in the archive of `job B`.
 
 The reason why it works this way is because the cache created for one runner
-often will not be valid when used by a different one which can run on a
+often isn't valid when used by a different one which can run on a
 **different architecture** (e.g., when the cache includes binary files). And
 since the different steps might be executed by runners running on different
 machines, it is a safe default.
@@ -472,7 +472,7 @@ Let's explore some examples.
 #### Examples
 
 Let's assume you have only one runner assigned to your project, so the cache
-will be stored in the runner's machine by default. If two jobs, A and B,
+is stored in the runner's machine by default. If two jobs, A and B,
 have the same cache key, but they cache different paths, cache B would overwrite
 cache A, even if their `paths` don't match:
 
@@ -506,15 +506,15 @@ job B:
 1. `job B` runs.
 1. The previous cache, if any, is unzipped.
 1. `vendor/` is cached as cache.zip and overwrites the previous one.
-1. The next time `job A` runs it will use the cache of `job B` which is different
-   and thus will be ineffective.
+1. The next time `job A` runs it uses the cache of `job B` which is different
+   and thus isn't effective.
 
 To fix that, use different `keys` for each job.
 
 In another case, let's assume you have more than one runner assigned to your
 project, but the distributed cache is not enabled. The second time the
 pipeline is run, we want `job A` and `job B` to re-use their cache (which in this case
-will be different):
+is different):
 
 ```yaml
 stages:
@@ -553,7 +553,7 @@ To start with a fresh copy of the cache, there are two ways to do that.
 ### Clearing the cache by changing `cache:key`
 
 All you have to do is set a new `cache: key` in your `.gitlab-ci.yml`. In the
-next run of the pipeline, the cache will be stored in a different location.
+next run of the pipeline, the cache is stored in a different location.
 
 ### Clearing the cache manually
 
@@ -567,7 +567,7 @@ via GitLab's UI:
 
    ![Clear runner caches](img/clear_runners_cache.png)
 
-1. On the next push, your CI/CD job will use a new cache.
+1. On the next push, your CI/CD job uses a new cache.
 
 Behind the scenes, this works by increasing a counter in the database, and the
 value of that counter is used to create the key for the cache by appending an
diff --git a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
index f8e2a2b7eb0..8430fe4cd1b 100644
--- a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
@@ -19,12 +19,12 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
 
    ![Create project](img/external_repository.png)
 
-   GitLab will import the repository and enable [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository).
+   GitLab imports the repository and enables [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository).
 
 1. In GitLab create a
    [Personal Access Token](../../user/profile/personal_access_tokens.md)
-   with `api` scope. This will be used to authenticate requests from the web
-   hook that will be created in Bitbucket to notify GitLab of new commits.
+   with `api` scope. This is used to authenticate requests from the web
+   hook that is created in Bitbucket to notify GitLab of new commits.
 
 1. In Bitbucket, from **Settings > Webhooks**, create a new web hook to notify
    GitLab of new commits.
@@ -62,7 +62,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
 
 1. In Bitbucket, add a script to push the pipeline status to Bitbucket.
 
-   > Note: changes made in GitLab will be overwritten by any changes made
+   > Note: changes made in GitLab are overwritten by any changes made
    > upstream in Bitbucket.
 
    Create a file `build_status` and insert the script below and run
diff --git a/doc/ci/ci_cd_for_external_repos/github_integration.md b/doc/ci/ci_cd_for_external_repos/github_integration.md
index b6f885ff220..1060f576be3 100644
--- a/doc/ci/ci_cd_for_external_repos/github_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/github_integration.md
@@ -28,7 +28,7 @@ To perform a one-off authorization with GitHub to grant GitLab access your
 repositories:
 
 1. Open <https://github.com/settings/tokens/new> to create a **Personal Access
-   Token**. This token will be used to access your repository and push commit
+   Token**. This token is used to access your repository and push commit
    statuses to GitHub.
 
    The `repo` and `admin:repo_hook` should be enable to allow GitLab access to
@@ -43,12 +43,12 @@ repositories:
 
 1. In GitHub, add a `.gitlab-ci.yml` to [configure GitLab CI/CD](../quick_start/README.md).
 
-GitLab will:
+GitLab:
 
-1. Import the project.
-1. Enable [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
-1. Enable [GitHub project integration](../../user/project/integrations/github.md)
-1. Create a web hook on GitHub to notify GitLab of new commits.
+1. Imports the project.
+1. Enables [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
+1. Enables [GitHub project integration](../../user/project/integrations/github.md)
+1. Creates a web hook on GitHub to notify GitLab of new commits.
 
 ## Connect manually
 
@@ -57,7 +57,7 @@ To use **GitHub Enterprise** with **GitLab.com**, use this method.
 To manually enable GitLab CI/CD for your repository:
 
 1. In GitHub open <https://github.com/settings/tokens/new> create a **Personal
-   Access Token.** GitLab will use this token to access your repository and
+   Access Token.** GitLab uses this token to access your repository and
    push commit statuses.
 
    Enter a **Token description** and update the scope to allow:
@@ -68,7 +68,7 @@ To manually enable GitLab CI/CD for your repository:
    URL for your GitHub repository. If your project is private, use the personal
    access token you just created for authentication.
 
-   GitLab will automatically configure polling-based pull mirroring.
+   GitLab automatically configures polling-based pull mirroring.
 
 1. Still in GitLab, enable the [GitHub project integration](../../user/project/integrations/github.md)
    from **Settings > Integrations.**
diff --git a/doc/ci/ci_cd_for_external_repos/index.md b/doc/ci/ci_cd_for_external_repos/index.md
index ae6cb759d23..db90714fa6b 100644
--- a/doc/ci/ci_cd_for_external_repos/index.md
+++ b/doc/ci/ci_cd_for_external_repos/index.md
@@ -18,7 +18,7 @@ GitLab CI/CD can be used with:
 Instead of moving your entire project to GitLab, you can connect your
 external repository to get the benefits of GitLab CI/CD.
 
-Connecting an external repository will set up [repository mirroring](../../user/project/repository/repository_mirroring.md)
+Connecting an external repository sets up [repository mirroring](../../user/project/repository/repository_mirroring.md)
 and create a lightweight project with issues, merge requests, wiki, and
 snippets disabled. These features
 [can be re-enabled later](../../user/project/settings/index.md#sharing-and-permissions).
@@ -74,7 +74,7 @@ If changes are pushed to the branch referenced by the Pull Request and the
 Pull Request is still open, a pipeline for the external pull request is
 created.
 
-GitLab CI/CD will create 2 pipelines in this case. One for the
+GitLab CI/CD creates 2 pipelines in this case. One for the
 branch push and one for the external pull request.
 
 After the Pull Request is closed, no pipelines are created for the external pull
@@ -89,10 +89,10 @@ The variable names are prefixed with `CI_EXTERNAL_PULL_REQUEST_`.
 
 ### Limitations
 
-This feature currently does not support Pull Requests from fork repositories. Any Pull Requests from fork repositories will be ignored.  [Read more](https://gitlab.com/gitlab-org/gitlab/-/issues/5667).
+This feature currently does not support Pull Requests from fork repositories. Any Pull Requests from fork repositories are ignored. [Read more](https://gitlab.com/gitlab-org/gitlab/-/issues/5667).
 
-Given that GitLab will create 2 pipelines, if changes are pushed to a remote branch that
-references an open Pull Request, both will contribute to the status of the Pull Request
+Given that GitLab creates 2 pipelines, if changes are pushed to a remote branch that
+references an open Pull Request, both contribute to the status of the Pull Request
 via GitHub integration. If you want to exclusively run pipelines on external pull
 requests and not on branches you can add `except: [branches]` to the job specs.
 [Read more](https://gitlab.com/gitlab-org/gitlab/-/issues/24089#workaround).
diff --git a/doc/ci/directed_acyclic_graph/index.md b/doc/ci/directed_acyclic_graph/index.md
index 04f27c584b7..47cc6f8e677 100644
--- a/doc/ci/directed_acyclic_graph/index.md
+++ b/doc/ci/directed_acyclic_graph/index.md
@@ -17,7 +17,7 @@ be set up.
 
 For example, you may have a specific tool or separate website that is built
 as part of your main project. Using a DAG, you can specify the relationship between
-these jobs and GitLab will then execute the jobs as soon as possible instead of waiting
+these jobs and GitLab executes the jobs as soon as possible instead of waiting
 for each stage to complete.
 
 Unlike other DAG solutions for CI/CD, GitLab does not require you to choose one or the
@@ -44,9 +44,9 @@ It has a pipeline that looks like the following:
 | build_d | test_d | deploy_d |
 
 Using a DAG, you can relate the `_a` jobs to each other separately from the `_b` jobs,
-and even if service `a` takes a very long time to build, service `b` will not
-wait for it and will finish as quickly as it can. In this very same pipeline, `_c` and
-`_d` can be left alone and will run together in staged sequence just like any normal
+and even if service `a` takes a very long time to build, service `b` doesn't
+wait for it and finishes as quickly as it can. In this very same pipeline, `_c` and
+`_d` can be left alone and run together in staged sequence just like any normal
 GitLab pipeline.
 
 ## Use cases
@@ -60,7 +60,7 @@ but related microservices.
 
 Additionally, a DAG can help with general speediness of pipelines and helping
 to deliver fast feedback. By creating dependency relationships that don't unnecessarily
-block each other, your pipelines will run as quickly as possible regardless of
+block each other, your pipelines run as quickly as possible regardless of
 pipeline stages, ensuring output (including errors) is available to developers
 as quickly as possible.
 
@@ -88,13 +88,13 @@ are certain use cases that you may need to work around. For more information:
 > - It's enabled on GitLab.com.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-needs-visualization).
 
-The needs visualization makes it easier to visualize the relationships between dependent jobs in a DAG. This graph will display all the jobs in a pipeline that need or are needed by other jobs. Jobs with no relationships are not displayed in this view.
+The needs visualization makes it easier to visualize the relationships between dependent jobs in a DAG. This graph displays all the jobs in a pipeline that need or are needed by other jobs. Jobs with no relationships are not displayed in this view.
 
 To see the needs visualization, click on the **Needs** tab when viewing a pipeline that uses the `needs:` keyword.
 
 ![Needs visualization example](img/dag_graph_example_v13_1.png)
 
-Clicking a node will highlight all the job paths it depends on.
+Clicking a node highlights all the job paths it depends on.
 
 ![Needs visualization with path highlight](img/dag_graph_example_clicked_v13_1.png)
 
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index ebbfde09c67..3ef244ab473 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -381,7 +381,7 @@ content:
 
 Update the `config.toml` file to mount the file to
 `/etc/docker/daemon.json`. This would mount the file for **every**
-container that is created by GitLab Runner. The configuration will be
+container that is created by GitLab Runner. The configuration is
 picked up by the `dind` service.
 
 ```toml
diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md
index f9b09bada14..fdb13f384ce 100644
--- a/doc/ci/docker/using_kaniko.md
+++ b/doc/ci/docker/using_kaniko.md
@@ -37,8 +37,8 @@ few important details:
 - The kaniko debug image is recommended (`gcr.io/kaniko-project/executor:debug`)
   because it has a shell, and a shell is required for an image to be used with
   GitLab CI/CD.
-- The entrypoint will need to be [overridden](using_docker_images.md#overriding-the-entrypoint-of-an-image),
-  otherwise the build script will not run.
+- The entrypoint needs to be [overridden](using_docker_images.md#overriding-the-entrypoint-of-an-image),
+  otherwise the build script doesn't run.
 - A Docker `config.json` file needs to be created with the authentication
   information for the desired container registry.
 
@@ -47,7 +47,7 @@ In the following example, kaniko is used to:
 1. Build a Docker image.
 1. Then push it to [GitLab Container Registry](../../user/packages/container_registry/index.md).
 
-The job will run only when a tag is pushed. A `config.json` file is created under
+The job runs only when a tag is pushed. A `config.json` file is created under
 `/kaniko/.docker` with the needed GitLab Container Registry credentials taken from the
 [environment variables](../variables/README.md#predefined-environment-variables)
 GitLab CI/CD provides.
diff --git a/doc/ci/examples/php.md b/doc/ci/examples/php.md
index 699d04f632c..85f0424554a 100644
--- a/doc/ci/examples/php.md
+++ b/doc/ci/examples/php.md
@@ -15,17 +15,17 @@ using the Shell executor.
 ## Test PHP projects using the Docker executor
 
 While it is possible to test PHP apps on any system, this would require manual
-configuration from the developer. To overcome this we will be using the
+configuration from the developer. To overcome this we use the
 official [PHP Docker image](https://hub.docker.com/_/php) that can be found in Docker Hub.
 
-This will allow us to test PHP projects against different versions of PHP.
+This allows us to test PHP projects against different versions of PHP.
 However, not everything is plug 'n' play, you still need to configure some
 things manually.
 
 As with every job, you need to create a valid `.gitlab-ci.yml` describing the
 build environment.
 
-Let's first specify the PHP image that will be used for the job process
+Let's first specify the PHP image that is used for the job process
 (you can read more about what an image means in the runner's lingo reading
 about [Using Docker images](../docker/using_docker_images.md#what-is-an-image)).
 
@@ -106,7 +106,7 @@ test:app:
 ### Test against different PHP versions in Docker builds
 
 Testing against multiple versions of PHP is super easy. Just add another job
-with a different Docker image version and the runner will do the rest:
+with a different Docker image version and the runner does the rest:
 
 ```yaml
 before_script:
@@ -128,7 +128,7 @@ test:7.0:
 
 ### Custom PHP configuration in Docker builds
 
-There are times where you will need to customise your PHP environment by
+There are times where you need to customise your PHP environment by
 putting your `.ini` file into `/usr/local/etc/php/conf.d/`. For that purpose
 add a `before_script` action:
 
@@ -168,7 +168,7 @@ The [phpenv](https://github.com/phpenv/phpenv) project allows you to easily mana
 each with its own configuration. This is especially useful when testing PHP projects
 with the Shell executor.
 
-You will have to install it on your build machine under the `gitlab-runner`
+You have to install it on your build machine under the `gitlab-runner`
 user following [the upstream installation guide](https://github.com/phpenv/phpenv#installation).
 
 Using phpenv also allows to easily configure the PHP environment with:
@@ -181,7 +181,7 @@ phpenv config-add my_config.ini
  [is abandoned](https://github.com/phpenv/phpenv/issues/57). There is a fork
  at [madumlao/phpenv](https://github.com/madumlao/phpenv) that tries to bring
  the project back to life. [CHH/phpenv](https://github.com/CHH/phpenv) also
- seems like a good alternative. Picking any of the mentioned tools will work
+ seems like a good alternative. Picking any of the mentioned tools works
  with the basic phpenv commands. Guiding you to choose the right phpenv is out
  of the scope of this tutorial.*
 
@@ -274,4 +274,4 @@ that runs on [GitLab.com](https://gitlab.com) using our publicly available
 [shared runners](../runners/README.md).
 
 Want to hack on it? Simply fork it, commit, and push your changes. Within a few
-moments the changes will be picked by a public runner and the job will begin.
+moments the changes are picked by a public runner and the job begins.
diff --git a/doc/ci/introduction/index.md b/doc/ci/introduction/index.md
index b24ee66fdba..4a296ddcd1c 100644
--- a/doc/ci/introduction/index.md
+++ b/doc/ci/introduction/index.md
@@ -8,7 +8,7 @@ type: concepts
 
 # Introduction to CI/CD with GitLab
 
-In this document, we'll present an overview of the concepts of Continuous Integration,
+This document presents an overview of the concepts of Continuous Integration,
 Continuous Delivery, and Continuous Deployment, as well as an introduction to
 GitLab CI/CD.
 
@@ -100,18 +100,18 @@ located in the root path of your repository.
 In this file, you can define the scripts you want to run, define include and
 cache dependencies, choose commands you want to run in sequence
 and those you want to run in parallel, define where you want to
-deploy your app, and specify whether you will want to run the scripts automatically
+deploy your app, and specify whether you want to run the scripts automatically
 or trigger any of them manually. After you're familiar with
 GitLab CI/CD you can add more advanced steps into the configuration file.
 
-To add scripts to that file, you'll need to organize them in a
+To add scripts to that file, you need to organize them in a
 sequence that suits your application and are in accordance with
 the tests you wish to perform. To visualize the process, imagine
 that all the scripts you add to the configuration file are the
 same as the commands you run on a terminal on your computer.
 
 After you've added your `.gitlab-ci.yml` configuration file to your
-repository, GitLab will detect it and run your scripts with the
+repository, GitLab detects it and run your scripts with the
 tool called [GitLab Runner](https://docs.gitlab.com/runner/), which
 works similarly to your terminal.
 
@@ -191,7 +191,7 @@ lifecycle, as shown in the illustration below.
 ![Deeper look into the basic CI/CD workflow](img/gitlab_workflow_example_extended_v12_3.png)
 
 If you look at the image from the left to the right,
-you'll see some of the features available in GitLab
+you can see some of the features available in GitLab
 according to each stage (Verify, Package, Release).
 
 1. **Verify**:
diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md
index ac9cda4e46c..1e405bfd9ec 100644
--- a/doc/ci/merge_request_pipelines/index.md
+++ b/doc/ci/merge_request_pipelines/index.md
@@ -57,7 +57,7 @@ When you use this method, you have to specify `only: - merge_requests` for each
 example, the pipeline contains a `test` job that is configured to run on merge requests.
 
 The `build` and `deploy` jobs don't have the `only: - merge_requests` keyword,
-so they will not run on merge requests.
+so they don't run on merge requests.
 
 ```yaml
 build:
@@ -82,7 +82,7 @@ deploy:
 #### Excluding certain jobs
 
 The behavior of the `only: [merge_requests]` keyword is such that _only_ jobs with
-that keyword are run in the context of a merge request; no other jobs will be run.
+that keyword are run in the context of a merge request; no other jobs run.
 
 However, you can invert this behavior and have all of your jobs run _except_
 for one or two.
@@ -120,8 +120,8 @@ C:
 
 Therefore:
 
-- Since `A` and `B` are getting the `only:` rule to execute in all cases, they will always run.
-- Since `C` specifies that it should only run for merge requests, it will not run for any pipeline
+- Since `A` and `B` are getting the `only:` rule to execute in all cases, they always run.
+- Since `C` specifies that it should only run for merge requests, it doesn't run for any pipeline
   except a merge request pipeline.
 
 This helps you avoid having to add the `only:` rule to all of your jobs to make
@@ -209,7 +209,7 @@ The variable names begin with the `CI_MERGE_REQUEST_` prefix.
 
 If you are experiencing duplicated pipelines when using `rules`, take a look at
 the [important differences between `rules` and `only`/`except`](../yaml/README.md#prevent-duplicate-pipelines),
-which will help you get your starting configuration correct.
+which helps you get your starting configuration correct.
 
 If you are seeing two pipelines when using `only/except`, please see the caveats
 related to using `only/except` above (or, consider moving to `rules`).
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
index 9c6fbba1337..28d205ad8b1 100644
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
+++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
@@ -19,8 +19,8 @@ the source branch have already been merged into the target branch.
 
 If the pipeline fails due to a problem in the target branch, you can wait until the
 target is fixed and re-run the pipeline.
-This new pipeline will run as if the source is merged with the updated target, and you
-will not need to rebase.
+This new pipeline runs as if the source is merged with the updated target, and you
+don't need to rebase.
 
 The pipeline does not automatically run when the target branch changes. Only changes
 to the source branch trigger a new pipeline. If a long time has passed since the last successful
@@ -33,7 +33,7 @@ When the merge request can't be merged, the pipeline runs against the source bra
 - The merge request is a [**Draft** merge request](../../../user/project/merge_requests/work_in_progress_merge_requests.md).
 
 In these cases, the pipeline runs as a [pipeline for merge requests](../index.md)
-and is labeled as `detached`. If these cases no longer exist, new pipelines will
+and is labeled as `detached`. If these cases no longer exist, new pipelines
 again run against the merged results.
 
 Any user who has developer [permissions](../../../user/permissions.md) can run a
@@ -71,7 +71,7 @@ GitLab [automatically displays](merge_trains/index.md#add-a-merge-request-to-a-m
 a **Start/Add Merge Train button**.
 
 Generally, this is a safer option than merging merge requests immediately, because your
-merge request will be evaluated with an expected post-merge result before the actual
+merge request is evaluated with an expected post-merge result before the actual
 merge happens.
 
 For more information, read the [documentation on Merge Trains](merge_trains/index.md).
@@ -84,10 +84,10 @@ GitLab CI/CD can detect the presence of redundant pipelines, and cancels them
 to conserve CI resources.
 
 When a user merges a merge request immediately within an ongoing merge
-train, the train will be reconstructed, as it will recreate the expected
+train, the train is reconstructed, because it recreates the expected
 post-merge commit and pipeline. In this case, the merge train may already
 have pipelines running against the previous expected post-merge commit.
-These pipelines are considered redundant and will be automatically
+These pipelines are considered redundant and are automatically
 canceled.
 
 ## Troubleshooting
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
index d4099cdeafd..a7d111f7ee6 100644
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
+++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
@@ -39,7 +39,7 @@ To add a merge request to a merge train, you need [permissions](../../../../user
 
 Each merge train can run a maximum of **twenty** pipelines in parallel.
 If more than twenty merge requests are added to the merge train, the merge requests
-will be queued until a slot in the merge train is free. There is no limit to the
+are queued until a slot in the merge train is free. There is no limit to the
 number of merge requests that can be queued.
 
 ## Merge train example
@@ -55,7 +55,7 @@ If the pipeline for `B` fails, it is removed from the train. The pipeline for
 `C` restarts with the `A` and `C` changes, but without the `B` changes.
 
 If `A` then completes successfully, it merges into the target branch, and `C` continues
-to run. If more merge requests are added to the train, they will now include the `A`
+to run. If more merge requests are added to the train, they now include the `A`
 changes that are included in the target branch, and the `C` changes that are from
 the merge request already in the train.
 
@@ -152,7 +152,7 @@ is recreated and all pipelines restart.
 ### Merge request dropped from the merge train immediately
 
 If a merge request is not mergeable (for example, it's a draft merge request, there is a merge
-conflict, etc.), your merge request will be dropped from the merge train automatically.
+conflict, etc.), your merge request is dropped from the merge train automatically.
 
 In these cases, the reason for dropping the merge request is in the **system notes**.
 
@@ -179,7 +179,7 @@ for more information.
 
 A Merge Train pipeline cannot be retried because the merge request is dropped from the merge train upon failure. For this reason, the retry button does not appear next to the pipeline icon.
 
-In the case of pipeline failure, you should [re-enqueue](#add-a-merge-request-to-a-merge-train) the merge request to the merge train, which will then initiate a new pipeline.
+In the case of pipeline failure, you should [re-enqueue](#add-a-merge-request-to-a-merge-train) the merge request to the merge train, which then initiates a new pipeline.
 
 ### Unable to add to merge train with message "The pipeline for this merge request failed."
 
@@ -195,9 +195,10 @@ you can clear the **Pipelines must succeed** check box and keep
 **Enable merge trains and pipelines for merged results** (merge trains) enabled.
 
 If you want to keep the **Pipelines must succeed** option enabled along with Merge
-Trains, you can create a new pipeline for merged results when this error occurs by
-going to the **Pipelines** tab and clicking **Run pipeline**. Then click
-**Start/Add to merge train when pipeline succeeds**.
+Trains, create a new pipeline for merged results when this error occurs:
+
+1. Go to the **Pipelines** tab and click **Run pipeline**.
+1. Click **Start/Add to merge train when pipeline succeeds**.
 
 See [the related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/35135)
 for more information.