Add latest changes from gitlab-org/gitlab@master

18 files changed, 171 insertions, 98 deletions

diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index e2e7e74be53..fd9ab9b5972 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -528,7 +528,7 @@ supported by consolidated configuration form, refer to the following guides:
 
 | Object storage type | Supported by consolidated configuration? |
 |---------------------|------------------------------------------|
-| [Backups](../raketasks/backup_gitlab.md#uploading-backups-to-a-remote-cloud-storage) | **{dotted-circle}** No |
+| [Backups](../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | **{dotted-circle}** No |
 | [Job artifacts](job_artifacts.md#using-object-storage) including archived job logs | **{check-circle}** Yes |
 | [LFS objects](lfs/index.md#storing-lfs-objects-in-remote-object-storage) | **{check-circle}** Yes |
 | [Uploads](uploads.md#using-object-storage) | **{check-circle}** Yes |
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index 8cd2b26ee42..f04351119ba 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -2207,7 +2207,7 @@ on what features you intend to use:
 
 |Object storage type|Supported by consolidated configuration?|
 |-------------------|----------------------------------------|
-| [Backups](../../raketasks/backup_gitlab.md#uploading-backups-to-a-remote-cloud-storage) | No |
+| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
 | [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
 | [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
 | [Uploads](../uploads.md#using-object-storage) | Yes |
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 07816dc7f8f..b7ab753eb75 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -2211,7 +2211,7 @@ on what features you intend to use:
 
 |Object storage type|Supported by consolidated configuration?|
 |-------------------|----------------------------------------|
-| [Backups](../../raketasks/backup_gitlab.md#uploading-backups-to-a-remote-cloud-storage) | No |
+| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
 | [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
 | [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
 | [Uploads](../uploads.md#using-object-storage) | Yes |
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index 0ef64bbdd55..265ff9b8882 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -922,7 +922,7 @@ on what features you intend to use:
 
 |Object storage type|Supported by consolidated configuration?|
 |-------------------|----------------------------------------|
-| [Backups](../../raketasks/backup_gitlab.md#uploading-backups-to-a-remote-cloud-storage) | No |
+| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
 | [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
 | [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
 | [Uploads](../uploads.md#using-object-storage) | Yes |
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index 50dde3084c4..4d90cac037b 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -2148,7 +2148,7 @@ on what features you intend to use:
 
 |Object storage type|Supported by consolidated configuration?|
 |-------------------|----------------------------------------|
-| [Backups](../../raketasks/backup_gitlab.md#uploading-backups-to-a-remote-cloud-storage) | No |
+| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
 | [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
 | [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
 | [Uploads](../uploads.md#using-object-storage) | Yes |
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index 5a5ad469e1e..ddf17b9a7af 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -2227,7 +2227,7 @@ on what features you intend to use:
 
 |Object storage type|Supported by consolidated configuration?|
 |-------------------|----------------------------------------|
-| [Backups](../../raketasks/backup_gitlab.md#uploading-backups-to-a-remote-cloud-storage) | No |
+| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
 | [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
 | [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
 | [Uploads](../uploads.md#using-object-storage) | Yes |
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 45352409aad..f79d019dc70 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -2148,7 +2148,7 @@ on what features you intend to use:
 
 |Object storage type|Supported by consolidated configuration?|
 |-------------------|----------------------------------------|
-| [Backups](../../raketasks/backup_gitlab.md#uploading-backups-to-a-remote-cloud-storage) | No |
+| [Backups](../../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | No |
 | [Job artifacts](../job_artifacts.md#using-object-storage) including archived job logs | Yes |
 | [LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
 | [Uploads](../uploads.md#using-object-storage) | Yes |
diff --git a/doc/administration/whats-new.md b/doc/administration/whats-new.md
index 05c769cf20c..9f0b58611ee 100644
--- a/doc/administration/whats-new.md
+++ b/doc/administration/whats-new.md
@@ -6,28 +6,30 @@ info: For assistance with this What's new page, see https://about.gitlab.com/han
 
 # What's new **(FREE)**
 
-With each monthly release, GitLab includes some of the highlights from the last 10
-GitLab versions in the **What's new** feature. To access it:
+You can view some of the highlights from the last 10
+GitLab versions in the **What's new** feature. It lists new features available in different
+[GitLab tiers](https://about.gitlab.com/pricing/).
 
-1. In the top navigation bar, select the **{question}** icon.
-1. Select **What's new** from the menu.
-
-The **What's new** describes new features available in multiple
-[GitLab tiers](https://about.gitlab.com/pricing/). While all users can see the
-feature list, the feature list is tailored to your subscription type:
+All users can see the feature list, but the entries might differ depending on the subscription type:
 
-- Features only available to self-managed installations are not shown on GitLab.com.
 - Features only available on GitLab.com are not shown to self-managed installations.
+- Features only available to self-managed installations are not shown on GitLab.com.
 
-## Self-managed installations
+   NOTE:
+   For self-managed installations, the updated **What's new** is included
+   in the first patch release after a new version, such as `13.10.1`.
 
-Due to our release post process, the content for **What's new** is not finalized
-when a new version (`.0` release) is cut. The updated **What's new** is included
-in the first patch release, such as `13.10.1`.
+## Access What's new
+
+To access the **What's new** feature:
+
+1. On the top bar, select the **{question}** icon.
+1. Select **What's new** from the menu.
 
-## Configure What's new variant
+## Configure What's new
 
-You can configure the What's new variant:
+You can configure **What's new** to display features based on the tier,
+or you can hide it. To configure it:
 
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > Preferences**, then expand **What's new**.
@@ -39,4 +41,4 @@ You can configure the What's new variant:
    | Enable What's new: Current tier only | What's new presents new features for your current subscription tier, while hiding new features not available to your subscription tier. |
    | Disable What's new | What's new is disabled and can no longer be viewed. |
 
-1. Save your changes.
+1. Select **Save changes**.
diff --git a/doc/api/deployments.md b/doc/api/deployments.md
index 01fa4e11884..8b99c21a385 100644
--- a/doc/api/deployments.md
+++ b/doc/api/deployments.md
@@ -58,6 +58,9 @@ Example response:
       "started_at": null,
       "status": "success",
       "tag": false,
+      "project": {
+        "ci_job_token_scope_enabled": false
+      },
       "user": {
         "id": 1,
         "name": "Administrator",
@@ -128,6 +131,9 @@ Example response:
       "started_at": null,
       "status": "success",
       "tag": false,
+      "project": {
+        "ci_job_token_scope_enabled": false
+      },  
       "user": {
         "id": 1,
         "name": "Administrator",
@@ -226,6 +232,9 @@ Example response:
     "created_at": "2016-08-11T11:32:24.456Z",
     "started_at": null,
     "finished_at": "2016-08-11T11:32:35.145Z",
+    "project": {
+      "ci_job_token_scope_enabled": false
+    },
     "user": {
       "id": 1,
       "name": "Administrator",
diff --git a/doc/api/environments.md b/doc/api/environments.md
index d67808bfd61..3f5f711e10b 100644
--- a/doc/api/environments.md
+++ b/doc/api/environments.md
@@ -68,6 +68,9 @@ Example response:
         "started_at": "2019-03-25T12:54:50.082Z",
         "finished_at": "2019-03-25T18:55:13.216Z",
         "duration": 21623.13423,
+        "project": {
+          "ci_job_token_scope_enabled": false
+        },
         "user": {
           "id": 1,
           "name": "Administrator",
@@ -180,6 +183,9 @@ Example of response
       "started_at": "2019-03-25T12:54:50.082Z",
       "finished_at": "2019-03-25T18:55:13.216Z",
       "duration": 21623.13423,
+      "project": {
+        "ci_job_token_scope_enabled": false
+      },
       "user": {
         "id": 1,
         "name": "Administrator",
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 7698cbc8178..d317b1e9be1 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -6088,6 +6088,29 @@ The edge type for [`BoardList`](#boardlist).
 | <a id="boardlistedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="boardlistedgenode"></a>`node` | [`BoardList`](#boardlist) | The item at the end of the edge. |
 
+#### `BranchRuleConnection`
+
+The connection type for [`BranchRule`](#branchrule).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="branchruleconnectionedges"></a>`edges` | [`[BranchRuleEdge]`](#branchruleedge) | A list of edges. |
+| <a id="branchruleconnectionnodes"></a>`nodes` | [`[BranchRule]`](#branchrule) | A list of nodes. |
+| <a id="branchruleconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `BranchRuleEdge`
+
+The edge type for [`BranchRule`](#branchrule).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="branchruleedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="branchruleedgenode"></a>`node` | [`BranchRule`](#branchrule) | The item at the end of the edge. |
+
 #### `CiBuildNeedConnection`
 
 The connection type for [`CiBuildNeed`](#cibuildneed).
@@ -9985,6 +10008,18 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="branchcommit"></a>`commit` | [`Commit`](#commit) | Commit for the branch. |
 | <a id="branchname"></a>`name` | [`String!`](#string) | Name of the branch. |
 
+### `BranchRule`
+
+List of branch rules for a project, grouped by branch name.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="branchrulecreatedat"></a>`createdAt` | [`Time!`](#time) | Timestamp of when the branch rule was created. |
+| <a id="branchrulename"></a>`name` | [`String!`](#string) | Branch name, with wildcards, for the branch rules. |
+| <a id="branchruleupdatedat"></a>`updatedAt` | [`Time!`](#time) | Timestamp of when the branch rule was last updated. |
+
 ### `BurnupChartDailyTotals`
 
 Represents the total number of issues and their weights for a particular day.
@@ -15589,6 +15624,7 @@ Represents vulnerability finding of a security report on the pipeline.
 | <a id="pipelinesecurityreportfindingassets"></a>`assets` | [`[AssetType!]`](#assettype) | List of assets associated with the vulnerability. |
 | <a id="pipelinesecurityreportfindingconfidence"></a>`confidence` | [`String`](#string) | Type of the security report that found the vulnerability. |
 | <a id="pipelinesecurityreportfindingdescription"></a>`description` | [`String`](#string) | Description of the vulnerability finding. |
+| <a id="pipelinesecurityreportfindingdescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | The GitLab Flavored Markdown rendering of `description`. |
 | <a id="pipelinesecurityreportfindingevidence"></a>`evidence` | [`VulnerabilityEvidence`](#vulnerabilityevidence) | Evidence for the vulnerability. |
 | <a id="pipelinesecurityreportfindingfalsepositive"></a>`falsePositive` | [`Boolean`](#boolean) | Indicates whether the vulnerability is a false positive. |
 | <a id="pipelinesecurityreportfindingidentifiers"></a>`identifiers` | [`[VulnerabilityIdentifier!]!`](#vulnerabilityidentifier) | Identifiers of the vulnerability finding. |
@@ -15618,6 +15654,7 @@ Represents vulnerability finding of a security report on the pipeline.
 | <a id="projectarchived"></a>`archived` | [`Boolean`](#boolean) | Indicates the archived status of the project. |
 | <a id="projectautoclosereferencedissues"></a>`autocloseReferencedIssues` | [`Boolean`](#boolean) | Indicates if issues referenced by merge requests and commits within the default branch are closed automatically. |
 | <a id="projectavatarurl"></a>`avatarUrl` | [`String`](#string) | URL to avatar image file of the project. |
+| <a id="projectbranchrules"></a>`branchRules` | [`BranchRuleConnection`](#branchruleconnection) | Branch rules configured for the project. (see [Connections](#connections)) |
 | <a id="projectcicdsettings"></a>`ciCdSettings` | [`ProjectCiCdSetting`](#projectcicdsetting) | CI/CD settings for the project. |
 | <a id="projectciconfigpathordefault"></a>`ciConfigPathOrDefault` | [`String!`](#string) | Path of the CI configuration file. |
 | <a id="projectcijobtokenscope"></a>`ciJobTokenScope` | [`CiJobTokenScopeType`](#cijobtokenscopetype) | The CI Job Tokens scope of access. |
diff --git a/doc/api/jobs.md b/doc/api/jobs.md
index 70838d6642e..3173b8f8e70 100644
--- a/doc/api/jobs.md
+++ b/doc/api/jobs.md
@@ -368,6 +368,9 @@ Example of response
     "status": "pending",
     "tag": false,
     "web_url": "https://example.com/foo/bar/-/jobs/7",
+    "project": {
+      "ci_job_token_scope_enabled": false
+    },
     "user": {
       "id": 1,
       "name": "Administrator",
@@ -454,6 +457,9 @@ Example of response
   "failure_reason": "script_failure",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/8",
+  "project": {
+    "ci_job_token_scope_enabled": false
+  },
   "user": {
     "id": 1,
     "name": "Administrator",
@@ -611,6 +617,9 @@ Example of response
   "status": "failed",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/8",
+  "project": {
+    "ci_job_token_scope_enabled": false
+  },
   "user": {
     "id": 1,
     "name": "Administrator",
@@ -701,6 +710,9 @@ Example of response
   "status": "canceled",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/1",
+  "project": {
+    "ci_job_token_scope_enabled": false
+  },
   "user": null
 }
 ```
@@ -751,6 +763,9 @@ Example of response
   "status": "pending",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/1",
+  "project": {
+    "ci_job_token_scope_enabled": false
+  },
   "user": null
 }
 ```
@@ -806,6 +821,9 @@ Example of response
   "status": "failed",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/1",
+  "project": {
+    "ci_job_token_scope_enabled": false
+  },
   "user": null
 }
 ```
@@ -882,6 +900,9 @@ Example response:
   "status": "pending",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/1",
+  "project": {
+    "ci_job_token_scope_enabled": false
+  },
   "user": null
 }
 ```
diff --git a/doc/development/geo.md b/doc/development/geo.md
index f042af42de5..1ae9d9ee32b 100644
--- a/doc/development/geo.md
+++ b/doc/development/geo.md
@@ -653,8 +653,7 @@ on, check out our [self-service framework](geo/framework.md).
 
 ### GET:Geo pipeline
 
-As part of the [package-and-qa](testing_guide/end_to_end/index.md#using-the-package-and-qa-job) pipeline, there is an option to manually trigger a job named `GET:Geo`. This
-pipeline uses [GET](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) to spin up a
+As part of the [e2e:package-and-test](testing_guide/end_to_end/index.md#using-the-package-and-test-job) pipeline, there is an option to manually trigger a job named `GET:Geo`. This pipeline uses [GET](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) to spin up a
 [1k](../administration/reference_architectures/1k_users.md) Geo installation,
 and run the [`gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa) Geo scenario against the instance.
 When working on Geo features, it is a good idea to ensure the `qa-geo` job passes in a triggered `GET:Geo pipeline`.
@@ -669,7 +668,7 @@ see the [QA documentation](https://gitlab.com/gitlab-org/gitlab/-/tree/master/qa
 
 The pipeline involves the interaction of multiple different projects:
 
-- [GitLab](https://gitlab.com/gitlab-org/gitlab) - The [package-and-qa job](testing_guide/end_to_end/index.md#using-the-package-and-qa-job) is launched from merge requests in this project.
+- [GitLab](https://gitlab.com/gitlab-org/gitlab) - The [`e2e:package-and-test` job](testing_guide/end_to_end/index.md#using-the-package-and-test-job) is launched from merge requests in this project.
 - [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab) - Builds relevant artifacts containing the changes from the triggering merge request pipeline.
 - [GET-Configs/Geo](https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit-configs/Geo) - Coordinates the lifecycle of a short-lived Geo installation that can be evaluated.
 - [GET](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) - Contains the necessary logic for creating and destroying Geo installations. Used by `GET-Configs/Geo`.
diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index 5f4a31ec633..4331e8e0ba8 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -8,16 +8,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## What is end-to-end testing?
 
-End-to-end testing is a strategy used to check whether your application works
+End-to-end (e2e) testing is a strategy used to check whether your application works
 as expected across the entire software stack and architecture, including
 integration of all micro-services and components that are supposed to work
 together.
 
 ## How do we test GitLab?
 
-We use [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab) to build GitLab packages and then we
-test these packages using the [GitLab QA orchestrator](https://gitlab.com/gitlab-org/gitlab-qa) tool, which is
-a black-box testing framework for the API and the UI.
+We use [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab) to build GitLab packages and then we test these packages 
+using the [GitLab QA orchestrator](https://gitlab.com/gitlab-org/gitlab-qa) tool to run the end-to-end tests located in the `qa` directory.
 
 ### Testing nightly builds
 
@@ -33,11 +32,9 @@ You can find these pipelines at <https://gitlab.com/gitlab-org/quality/staging/p
 
 ### Testing code in merge requests
 
-#### Using the `package-and-qa` job
+#### Using the package-and-test job
 
-It is possible to run end-to-end tests for a merge request, eventually being run in
-a pipeline in the [`gitlab-org/gitlab-qa-mirror`](https://gitlab.com/gitlab-org/gitlab-qa-mirror) project,
-by triggering the `package-and-qa` manual action in the `qa` stage (not
+It is possible to run end-to-end tests for a merge request by triggering the `e2e:package-and-test` manual action in the `qa` stage (not
 available for forks).
 
 **This runs end-to-end tests against a custom EE (with an Ultimate license)
@@ -72,38 +69,30 @@ subgraph "`gitlab-org/gitlab-qa-mirror` pipeline"
 ```
 
 1. In the [`gitlab-org/gitlab` pipeline](https://gitlab.com/gitlab-org/gitlab):
-   1. Developer triggers the `package-and-qa` manual action (available once the `build-qa-image` and
+   1. Developer triggers the `e2e:package-and-test` manual action (available once the `build-qa-image` and
       `build-assets-image` jobs are done), that can be found in GitLab merge
-      requests. This starts a chain of pipelines in multiple projects.
-   1. The script being executed triggers a pipeline in
+      requests. This starts a e2e test child pipeline.
+   1. E2E child pipeline triggers a downstream pipeline in
       [`gitlab-org/build/omnibus-gitlab-mirror`](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror)
       and polls for the resulting status. We call this a _status attribution_.
 
 1. In the [`gitlab-org/build/omnibus-gitlab-mirror` pipeline](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror):
    1. Docker image is being built and pushed to its Container Registry.
-   1. Finally, the `Trigger:qa-test` job triggers a new end-to-end pipeline in
-      [`gitlab-org/gitlab-qa-mirror`](https://gitlab.com/gitlab-org/gitlab-qa-mirror/pipelines) and polls for the resulting status.
+   1. Once Docker images are built and pushed jobs in `test` stage are started
 
-1. In the [`gitlab-org/gitlab-qa-mirror` pipeline](https://gitlab.com/gitlab-org/gitlab-qa-mirror):
+1. In the `Test` stage:
    1. Container for the Docker image stored in the [`gitlab-org/build/omnibus-gitlab-mirror`](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror) registry is spun-up.
    1. End-to-end tests are run with the `gitlab-qa` executable, which spin up a container for the end-to-end image from the [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab) registry.
 
-1. The result of the [`gitlab-org/gitlab-qa-mirror` pipeline](https://gitlab.com/gitlab-org/gitlab-qa-mirror) is being
-   propagated upstream (through polling from upstream pipelines), through [`gitlab-org/build/omnibus-gitlab-mirror`](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror), back to the [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab) merge request.
-
-We plan to [add more specific information](https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/156)
-about the tests included in each job/scenario that runs in `gitlab-org/gitlab-qa-mirror`.
-
 NOTE:
 You may have noticed that we use `gitlab-org/build/omnibus-gitlab-mirror` instead of
-`gitlab-org/omnibus-gitlab`, and `gitlab-org/gitlab-qa-mirror` instead of `gitlab-org/gitlab-qa`.
+`gitlab-org/omnibus-gitlab`.
 This is due to technical limitations in the GitLab permission model: the ability to run a pipeline
 against a protected branch is controlled by the ability to push/merge to this branch.
 This means that for developers to be able to trigger a pipeline for the default branch in
-`gitlab-org/omnibus-gitlab`/`gitlab-org/gitlab-qa`, they would need to have the
-Maintainer role for those projects.
+`gitlab-org/omnibus-gitlab`, they would need to have the Maintainer role for this project.
 For security reasons and implications, we couldn't open up the default branch to all the Developers.
-Hence we created these mirrors where Developers and Maintainers are allowed to push/merge to the default branch.
+Hence we created this mirror where Developers and Maintainers are allowed to push/merge to the default branch.
 This problem was discovered in <https://gitlab.com/gitlab-org/gitlab-qa/-/issues/63#note_107175160> and the "mirror"
 work-around was suggested in <https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4717>.
 A feature proposal to segregate access control regarding running pipelines from ability to push/merge was also created at <https://gitlab.com/gitlab-org/gitlab/-/issues/24585>.
@@ -231,7 +220,7 @@ a link to the current test report.
 
 Each type of scheduled pipeline generates a static link for the latest test report according to its stage:
 
-- [`master`](https://storage.googleapis.com/gitlab-qa-allure-reports/package-and-qa/master/index.html)
+- [`master`](https://storage.googleapis.com/gitlab-qa-allure-reports/e2e-package-and-test/master/index.html)
 - [`staging-full`](https://storage.googleapis.com/gitlab-qa-allure-reports/staging-full/master/index.html)
 - [`staging-sanity`](https://storage.googleapis.com/gitlab-qa-allure-reports/staging-sanity/master/index.html)
 - [`staging-sanity-no-admin`](https://storage.googleapis.com/gitlab-qa-allure-reports/staging-sanity-no-admin/master/index.html)
diff --git a/doc/raketasks/backup_gitlab.md b/doc/raketasks/backup_gitlab.md
index 7966e47f44c..3f241ef2f05 100644
--- a/doc/raketasks/backup_gitlab.md
+++ b/doc/raketasks/backup_gitlab.md
@@ -262,7 +262,7 @@ sudo -u git -H bundle exec rake gitlab:backup:create SKIP=db,uploads RAILS_ENV=p
 ### Skipping tar creation
 
 NOTE:
-It is not possible to skip the tar creation when using [object storage](#uploading-backups-to-a-remote-cloud-storage) for backups.
+It is not possible to skip the tar creation when using [object storage](#upload-backups-to-a-remote-cloud-storage) for backups.
 
 The last part of creating a backup is generation of a `.tar` file containing
 all the parts. In some cases (for example, if the backup is picked up by other
@@ -391,7 +391,7 @@ For example, to back up all repositories for all projects in **Group A** (`group
   sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_PATHS=group-a,group-b/project-c
   ```
 
-### Uploading backups to a remote (cloud) storage
+### Upload backups to a remote (cloud) storage
 
 NOTE:
 It is not possible to [skip the tar creation](#skipping-tar-creation) when using object storage for backups.
@@ -401,7 +401,7 @@ the `.tar` file it creates. In the following example, we use Amazon S3 for
 storage, but Fog also lets you use [other storage providers](https://fog.io/storage/).
 GitLab also [imports cloud drivers](https://gitlab.com/gitlab-org/gitlab/-/blob/da46c9655962df7d49caef0e2b9f6bbe88462a02/Gemfile#L113)
 for AWS, Google, OpenStack Swift, Rackspace, and Aliyun. A local driver is
-[also available](#uploading-to-locally-mounted-shares).
+[also available](#upload-to-locally-mounted-shares).
 
 [Read more about using object storage with GitLab](../administration/object_storage.md).
 
@@ -722,7 +722,7 @@ Users of GitLab 12.1 and earlier should use the command `gitlab-rake gitlab:back
 
 ### Skip uploading backups to remote storage
 
-If you have configured GitLab to [upload backups in a remote storage](#uploading-backups-to-a-remote-cloud-storage),
+If you have configured GitLab to [upload backups in a remote storage](#upload-backups-to-a-remote-cloud-storage),
 you can use the `SKIP=remote` option to skip uploading your backups to the remote storage.
 
 For Omnibus GitLab packages:
@@ -737,23 +737,40 @@ For installations from source:
 sudo -u git -H bundle exec rake gitlab:backup:create SKIP=remote RAILS_ENV=production
 ```
 
-### Uploading to locally mounted shares
+### Upload to locally-mounted shares
 
-You may also send backups to a mounted share (for example, `NFS`,`CIFS`, or
-`SMB`) by using the Fog [`Local`](https://github.com/fog/fog-local#usage)
-storage provider. The directory pointed to by the `local_root` key _must_ be
-owned by the `git` user _when mounted_ (mounting with the `uid=` of the `git`
-user for `CIFS` and `SMB`) or the user that you are executing the backup tasks
-as (for Omnibus packages, this is the `git` user).
+You can send backups to a locally-mounted share (for example, `NFS`,`CIFS`, or `SMB`) using the Fog
+[`Local`](https://github.com/fog/fog-local#usage) storage provider.
 
-The `backup_upload_remote_directory` _must_ be set in addition to the
-`local_root` key. This is the sub directory inside the mounted directory that
-backups are copied to, and is created if it does not exist. If the
-directory that you want to copy the tarballs to is the root of your mounted
-directory, use `.` instead.
+To do this, you must set the following configuration keys:
+
+- `backup_upload_remote_directory`: mounted directory that backups are copied to.
+- `backup_upload_connection.local_root`: subdirectory of the `backup_upload_remote_directory` directory. It is created if it doesn't exist.
+  If you want to copy the tarballs to the root of your mounted directory, use `.`.
+
+When mounted, the directory set in the `local_root` key must be owned by either:
+
+- The `git` user. So, mounting with the `uid=` of the `git` user for `CIFS` and `SMB`.
+- The user that you are executing the backup tasks as. For Omnibus GitLab, this is the `git` user.
 
 Because file system performance may affect overall GitLab performance,
-[GitLab doesn't recommend using cloud-based file systems for storage](../administration/nfs.md#avoid-using-cloud-based-file-systems).
+[we don't recommend using cloud-based file systems for storage](../administration/nfs.md#avoid-using-cloud-based-file-systems).
+
+#### Avoid conflicting configuration
+
+Don't set the following configuration keys to the same path:
+
+- `gitlab_rails['backup_path']` (`backup.path` for source installations).
+- `gitlab_rails['backup_upload_connection'].local_root` (`backup.upload.connection.local_root` for source installations).
+
+The `backup_path` configuration key sets the local location of the backup file. The `upload` configuration key is
+intended for use when the backup file is uploaded to a separate server, perhaps for archival purposes.
+
+If these configuration keys are set to the same location, the upload feature fails because a backup already exists at
+the upload location. This failure causes the upload feature to delete the backup because it assumes it's a residual file
+remaining after the failed upload attempt.
+
+#### Configure uploads to locally-mounted shares
 
 For Omnibus GitLab packages:
 
@@ -878,7 +895,7 @@ for backups. The next time the backup task runs, backups older than the `backup_
 pruned.
 
 This configuration option manages only local files. GitLab doesn't prune old
-files stored in a third-party [object storage](#uploading-backups-to-a-remote-cloud-storage)
+files stored in a third-party [object storage](#upload-backups-to-a-remote-cloud-storage)
 because the user may not have permission to list and delete files. It's
 recommended that you configure the appropriate retention policy for your object
 storage (for example, [AWS S3](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)).
diff --git a/doc/user/project/integrations/img/mattermost_bot_auth.png b/doc/user/project/integrations/img/mattermost_bot_auth.png
deleted file mode 100644
index a05d8da1237..00000000000
--- a/doc/user/project/integrations/img/mattermost_bot_auth.png
+++ /dev/null
diff --git a/doc/user/project/integrations/img/mattermost_bot_available_commands.png b/doc/user/project/integrations/img/mattermost_bot_available_commands.png
deleted file mode 100644
index 3232ccc3451..00000000000
--- a/doc/user/project/integrations/img/mattermost_bot_available_commands.png
+++ /dev/null
diff --git a/doc/user/project/integrations/mattermost_slash_commands.md b/doc/user/project/integrations/mattermost_slash_commands.md
index 42f28ed815f..25fd3f0e0bf 100644
--- a/doc/user/project/integrations/mattermost_slash_commands.md
+++ b/doc/user/project/integrations/mattermost_slash_commands.md
@@ -104,18 +104,20 @@ provide to GitLab:
 
 Your slash command can now communicate with your GitLab project.
 
-## Authorizing Mattermost to interact with GitLab
+## Connect your GitLab account to Mattermost
 
-The first time a user interacts with the newly created slash commands,
-Mattermost triggers an authorization process.
+Prerequisite:
 
-![Mattermost bot authorize](img/mattermost_bot_auth.png)
+- To run [slash commands](#available-slash-commands), you must have
+  [permission](../../permissions.md#project-members-permissions) to
+  perform the action in the GitLab project.
 
-This connects your Mattermost user with your GitLab user. You can
-see all authorized chat accounts in your profile's page under **Chat**.
+To interact with GitLab using Mattermost slash commands:
 
-When the authorization process is complete, you can start interacting with
-GitLab using the Mattermost commands.
+1. In a Mattermost chat environment, run your new slash command.
+1. Select **connect your GitLab account** to authorize access.
+
+You can see all authorized chat accounts in your Mattermost profile page under **Chat**.
 
 ## Available slash commands
 
@@ -123,30 +125,21 @@ The available slash commands for Mattermost are:
 
 | Command | Description | Example |
 | ------- | ----------- | ------- |
-| <kbd>/&lt;trigger&gt; issue new &lt;title&gt; <kbd>⇧ Shift</kbd>+<kbd>↵ Enter</kbd> &lt;description&gt;</kbd> | Create a new issue in the project that `<trigger>` is tied to. `<description>` is optional. | `/gitlab issue new We need to change the homepage` |
-| <kbd>/&lt;trigger&gt; issue show &lt;issue-number&gt;</kbd> | Show the issue with ID `<issue-number>` from the project that `<trigger>` is tied to. | `/gitlab issue show 42` |
-| <kbd>/&lt;trigger&gt; deploy &lt;environment&gt; to &lt;environment&gt;</kbd> | Start the CI job that deploys from one environment to another, for example `staging` to `production`. CI/CD must be [properly configured](../../../ci/yaml/index.md). | `/gitlab deploy staging to production` |
-
-To see a list of available commands to interact with GitLab, type the
-trigger word followed by <kbd>help</kbd>. Example: `/gitlab help`
+| `/<trigger> issue new <title>` <kbd>Shift</kbd>+<kbd>Enter</kbd> `<description>` | Create a new issue in the project that `<trigger>` is tied to. `<description>` is optional. | `/gitlab issue new We need to change the homepage` |
+| `/<trigger> issue show <issue-number>` | Show the issue with ID `<issue-number>` from the project that `<trigger>` is tied to. | `/gitlab issue show 42` |
+| `/<trigger> deploy <environment> to <environment>` | Start the CI/CD job that deploys from one environment to another (for example, `staging` to `production`). CI/CD must be [properly configured](../../../ci/yaml/index.md). | `/gitlab deploy staging to production` |
+| `/<trigger> help` | View a list of available slash commands. | `/gitlab help` |
 
-![Mattermost bot available commands](img/mattermost_bot_available_commands.png)
+## Related topics
 
-## Permissions
-
-The permissions to run the [available commands](#available-slash-commands) derive from
-the [permissions you have on the project](../../permissions.md#project-members-permissions).
+- [Mattermost slash commands](https://developers.mattermost.com/integrate/slash-commands/)
+- [Omnibus GitLab Mattermost](../../../integration/mattermost/)
 
 ## Troubleshooting
 
-If an event is not being triggered, confirm that the channel you're using is a public one.
-Mattermost webhooks do not have access to private channels.
+When a Mattermost slash command does not trigger an event in GitLab:
 
-If a private channel is required, you can edit the webhook's channel in Mattermost and
-select a private channel. It is not possible to use different channels for
-different types of notifications. All events are sent to the specified channel.
-
-## Further reading
-
-- [Mattermost slash commands documentation](https://docs.mattermost.com/developer/slash-commands.html)
-- [Omnibus GitLab Mattermost](../../../integration/mattermost/)
+- Ensure you're using a public channel.
+  Mattermost webhooks do not have access to private channels.
+- If you require a private channel, edit the webhook channel,
+  and select a private one. All events are sent to the specified channel.