diff --git a/app/services/concerns/update_repository_storage_methods.rb b/app/services/concerns/update_repository_storage_methods.rb
index 6e4824bd784..cbcd0b7f56b 100644
--- a/app/services/concerns/update_repository_storage_methods.rb
+++ b/app/services/concerns/update_repository_storage_methods.rb
@@ -38,11 +38,7 @@ module UpdateRepositoryStorageMethods
   rescue StandardError => e
     repository_storage_move.do_fail!
 
-    Gitlab::ErrorTracking.track_exception(e, container_klass: container.class.to_s, container_path: container.full_path)
-
-    ServiceResponse.error(
-      message: s_("UpdateRepositoryStorage|Error moving repository storage for %{container_full_path} - %{message}") % { container_full_path: container.full_path, message: e.message }
-    )
+    Gitlab::ErrorTracking.track_and_raise_exception(e, container_klass: container.class.to_s, container_path: container.full_path)
   end
 
   private
diff --git a/bin/background_jobs_sk b/bin/background_jobs_sk
index 0aab69126b2..0e9a5365d44 100755
--- a/bin/background_jobs_sk
+++ b/bin/background_jobs_sk
@@ -24,13 +24,13 @@ restart()
   fi
 
   pkill -u $gitlab_user -f 'sidekiq [0-9]'
-  start_sidekiq -P $sidekiq_pidfile -d -L $sidekiq_logfile >> $sidekiq_logfile 2>&1
+  start_sidekiq -P $sidekiq_pidfile -d -L $sidekiq_logfile "$@" >> $sidekiq_logfile 2>&1
 }
 
 # Starts on foreground but output to the logfile instead stdout.
 start_silent()
 {
-  start_sidekiq >> $sidekiq_logfile 2>&1
+  start_sidekiq "$@" >> $sidekiq_logfile 2>&1
 }
 
 start_sidekiq()
@@ -50,17 +50,17 @@ case "$1" in
     stop
     ;;
   start)
-    restart
+    restart "$@"
     ;;
   start_silent)
     warn "Deprecated: Will be removed at 13.0 (see https://gitlab.com/gitlab-org/gitlab/-/issues/196731)."
     start_silent
     ;;
   start_foreground)
-    start_sidekiq
+    start_sidekiq "$@"
     ;;
   restart)
-    restart
+    restart "$@"
     ;;
   *)
     echo "Usage: RAILS_ENV=<env> $0 {stop|start|start_silent|start_foreground|restart}"
diff --git a/bin/background_jobs_sk_cluster b/bin/background_jobs_sk_cluster
index 6188ec51420..d48b5484fce 100755
--- a/bin/background_jobs_sk_cluster
+++ b/bin/background_jobs_sk_cluster
@@ -11,7 +11,7 @@ warn()
   echo "$@" 1>&2
 }
 
-get_sidekiq_pid() 
+get_sidekiq_pid()
 {
   if [ ! -f $sidekiq_pidfile ]; then
     warn "No pidfile found at $sidekiq_pidfile; is Sidekiq running?"
@@ -37,7 +37,7 @@ restart()
   fi
 
   warn "Sidekiq output will be written to $sidekiq_logfile"
-  start_sidekiq >> $sidekiq_logfile 2>&1
+  start_sidekiq "$@" >> $sidekiq_logfile 2>&1
 }
 
 start_sidekiq()
@@ -55,7 +55,7 @@ start_sidekiq()
     processes_args+=("*")
   done
 
-  ${cmd} bin/sidekiq-cluster "${processes_args[@]}" -P $sidekiq_pidfile -e $RAILS_ENV
+  ${cmd} bin/sidekiq-cluster "${processes_args[@]}" -P $sidekiq_pidfile -e $RAILS_ENV "$@"
 }
 
 case "$1" in
@@ -63,13 +63,13 @@ case "$1" in
     stop
     ;;
   start)
-    restart &
+    restart "$@" &
     ;;
   start_foreground)
-    start_sidekiq
+    start_sidekiq "$@"
     ;;
   restart)
-    restart &
+    restart "$@" &
     ;;
   *)
     echo "Usage: RAILS_ENV=<env> SIDEKIQ_WORKERS=<n> $0 {stop|start|start_foreground|restart}"
diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 3cfbc8ae74b..057ee7a7eb3 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -120,7 +120,8 @@ From there, you can see the following actions:
 - Project access token was successfully created or revoked ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230007) in GitLab 13.9)
 - Failed attempt to create or revoke a project access token ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230007) in GitLab 13.9)
 - When default branch changes for a project ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/52339) in GitLab 13.9)
-- Created, updated, or deleted DAST profiles, DAST scanner profiles, and DAST site profiles ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217872))
+- Created, updated, or deleted DAST profiles, DAST scanner profiles, and DAST site profiles
+  ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) in GitLab 14.1)
 
 Project events can also be accessed via the [Project Audit Events API](../api/audit_events.md#project-audit-events).
 
diff --git a/doc/ci/pipelines/img/pipelines_graph_dependency_view_hover_v13_12.png b/doc/ci/pipelines/img/pipelines_graph_dependency_view_hover_v13_12.png
index e73845b39b0..ff6b3af0a28 100644
Binary files a/doc/ci/pipelines/img/pipelines_graph_dependency_view_hover_v13_12.png and b/doc/ci/pipelines/img/pipelines_graph_dependency_view_hover_v13_12.png differ
diff --git a/doc/ci/pipelines/img/pipelines_graph_dependency_view_links_v13_12.png b/doc/ci/pipelines/img/pipelines_graph_dependency_view_links_v13_12.png
index 1ce77881bc4..b0923ab96d9 100644
Binary files a/doc/ci/pipelines/img/pipelines_graph_dependency_view_links_v13_12.png and b/doc/ci/pipelines/img/pipelines_graph_dependency_view_links_v13_12.png differ
diff --git a/doc/ci/pipelines/img/pipelines_graph_dependency_view_v13_12.png b/doc/ci/pipelines/img/pipelines_graph_dependency_view_v13_12.png
index 41840108441..ae7cdc5b43e 100644
Binary files a/doc/ci/pipelines/img/pipelines_graph_dependency_view_v13_12.png and b/doc/ci/pipelines/img/pipelines_graph_dependency_view_v13_12.png differ
diff --git a/doc/ci/pipelines/img/pipelines_graph_stage_view_v13_12.png b/doc/ci/pipelines/img/pipelines_graph_stage_view_v13_12.png
index d7d8f3c63d2..b3b98313350 100644
Binary files a/doc/ci/pipelines/img/pipelines_graph_stage_view_v13_12.png and b/doc/ci/pipelines/img/pipelines_graph_stage_view_v13_12.png differ
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 683939ac81a..21416d003ea 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -6,21 +6,133 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/pipelines/settings.h
 type: reference, howto
 ---
 
-# Pipeline settings **(FREE)**
+# Customize pipeline configuration **(FREE)**
 
-To reach the pipelines settings navigate to your project's
-**Settings > CI/CD**.
-
-The following settings can be configured per project.
+You can customize how pipelines run for your project.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For an overview, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s).
+For an overview of pipelines, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s).
 Watch also [GitLab CI pipeline tutorial for beginners](https://www.youtube.com/watch?v=Jav4vbUrqII).
 
-You can use the pipeline status to determine if a merge request can be merged:
+## Visibility of pipelines
 
-- [Merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md).
-- [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).
+Pipeline visibility is determined by:
+
+- Your current [user access level](../../user/permissions.md).
+- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
+
+NOTE:
+If the project visibility is set to **Private**, the [**Public pipelines** setting has no effect](../enable_or_disable_ci.md#per-project-user-setting).
+
+This also determines the visibility of these related features:
+
+- Job output logs
+- Job artifacts
+- The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)**
+
+Job logs and artifacts are [not visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
+
+If **Public pipelines** is enabled (default):
+
+- For **public** projects, anyone can view the pipelines and related features.
+- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines
+  and related features.
+- For **private** projects, any project member (Guest or higher) can view the pipelines
+  and related features.
+
+If **Public pipelines** is disabled:
+
+- For **public** projects, anyone can view the pipelines, but only members
+  (Reporter or higher) can access the related features.
+- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines.
+  However, only members (reporter or higher) can access the job related features.
+- For **private** projects, only project members (reporter or higher)
+  can view the pipelines or access the related features.
+
+## Auto-cancel redundant pipelines
+
+You can set pending or running pipelines to cancel automatically when a new pipeline runs on the same branch. You can enable this in the project settings:
+
+1. Go to **Settings > CI/CD**.
+1. Expand **General Pipelines**.
+1. Check the **Auto-cancel redundant pipelines** checkbox.
+1. Click **Save changes**.
+
+Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
+running job can be cancelled before it completes.
+
+## Skip outdated deployment jobs
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25276) in GitLab 12.9.
+
+Your project may have multiple concurrent deployment jobs that are
+scheduled to run in the same time frame.
+
+This can lead to a situation where an older deployment job runs after a
+newer one, which may not be what you want.
+
+To avoid this scenario:
+
+1. Go to **Settings > CI/CD**.
+1. Expand **General pipelines**.
+1. Check the **Skip outdated deployment jobs** checkbox.
+1. Click **Save changes**.
+
+When enabled, any older deployments job are skipped when a new deployment starts.
+
+For more information, see [Deployment safety](../environments/deployment_safety.md).
+
+## Retry outdated jobs
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211339) in GitLab 13.6.
+
+A deployment job can fail because a newer one has run. If you retry the failed deployment job, the
+environment could be overwritten with older source code. If you click **Retry**, a modal warns you
+about this and asks for confirmation.
+
+For more information, see [Deployment safety](../environments/deployment_safety.md).
+
+## Custom CI/CD configuration file
+
+> [Support for external `.gitlab-ci.yml` locations](https://gitlab.com/gitlab-org/gitlab/-/issues/14376) introduced in GitLab 12.6.
+
+By default we look for the `.gitlab-ci.yml` file in the project's root
+directory. If needed, you can specify an alternate path and filename, including locations outside the project.
+
+To customize the path:
+
+1. Go to the project's **Settings > CI/CD**.
+1. Expand the **General pipelines** section.
+1. Provide a value in the **CI/CD configuration file** field.
+1. Click **Save changes**.
+
+If the CI/CD configuration file is stored in the repository in a non-default
+location, the path must be relative to the root directory. Examples of valid
+paths and file names include:
+
+- `.gitlab-ci.yml` (default)
+- `.my-custom-file.yml`
+- `my/path/.gitlab-ci.yml`
+- `my/path/.my-custom-file.yml`
+
+If hosting the CI/CD configuration file on an external site, the URL link must end with `.yml`:
+
+- `http://example.com/generate/ci/config.yml`
+
+If hosting the CI/CD configuration file in a different project in GitLab, the path must be relative
+to the root directory in the other project. Include the group and project name at the end:
+
+- `.gitlab-ci.yml@mygroup/another-project`
+- `my/path/.my-custom-file.yml@mygroup/another-project`
+
+Hosting the configuration file in a separate project allows stricter control of the
+configuration file. For example:
+
+- Create a public project to host the configuration file.
+- Give write permissions on the project only to users who are allowed to edit the file.
+
+Other users and projects can access the configuration file without being
+able to edit it.
 
 ## Git strategy
 
@@ -68,53 +180,6 @@ if the job surpasses the threshold, it is marked as failed.
 Project defined timeout (either specific timeout set by user or the default
 60 minutes timeout) may be [overridden for runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
 
-## Maximum artifacts size **(FREE SELF)**
-
-For information about setting a maximum artifact size for a project, see
-[Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
-
-## Custom CI/CD configuration file
-
-> [Support for external `.gitlab-ci.yml` locations](https://gitlab.com/gitlab-org/gitlab/-/issues/14376) introduced in GitLab 12.6.
-
-By default we look for the `.gitlab-ci.yml` file in the project's root
-directory. If needed, you can specify an alternate path and filename, including locations outside the project.
-
-To customize the path:
-
-1. Go to the project's **Settings > CI/CD**.
-1. Expand the **General pipelines** section.
-1. Provide a value in the **CI/CD configuration file** field.
-1. Click **Save changes**.
-
-If the CI/CD configuration file is stored in the repository in a non-default
-location, the path must be relative to the root directory. Examples of valid
-paths and file names include:
-
-- `.gitlab-ci.yml` (default)
-- `.my-custom-file.yml`
-- `my/path/.gitlab-ci.yml`
-- `my/path/.my-custom-file.yml`
-
-If hosting the CI/CD configuration file on an external site, the URL link must end with `.yml`:
-
-- `http://example.com/generate/ci/config.yml`
-
-If hosting the CI/CD configuration file in a different project in GitLab, the path must be relative
-to the root directory in the other project. Include the group and project name at the end:
-
-- `.gitlab-ci.yml@mygroup/another-project`
-- `my/path/.my-custom-file.yml@mygroup/another-project`
-
-Hosting the configuration file in a separate project allows stricter control of the
-configuration file. For example:
-
-- Create a public project to host the configuration file.
-- Give write permissions on the project only to users who are allowed to edit the file.
-
-Other users and projects can access the configuration file without being
-able to edit it.
-
 ## Test coverage parsing
 
 If you use test coverage in your code, GitLab can capture its output in the
@@ -184,84 +249,6 @@ For example:
 lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'
 ```
 
-## Visibility of pipelines
-
-Pipeline visibility is determined by:
-
-- Your current [user access level](../../user/permissions.md).
-- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
-
-NOTE:
-If the project visibility is set to **Private**, the [**Public pipelines** setting has no effect](../enable_or_disable_ci.md#per-project-user-setting).
-
-This also determines the visibility of these related features:
-
-- Job output logs
-- Job artifacts
-- The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)**
-
-Job logs and artifacts are [not visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
-
-If **Public pipelines** is enabled (default):
-
-- For **public** projects, anyone can view the pipelines and related features.
-- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines
-  and related features.
-- For **private** projects, any project member (guest or higher) can view the pipelines
-  and related features.
-
-If **Public pipelines** is disabled:
-
-- For **public** projects, anyone can view the pipelines, but only members
-  (reporter or higher) can access the related features.
-- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines.
-  However, only members (reporter or higher) can access the job related features.
-- For **private** projects, only project members (reporter or higher)
-  can view the pipelines or access the related features.
-
-## Auto-cancel redundant pipelines
-
-You can set pending or running pipelines to cancel automatically when a new pipeline runs on the same branch. You can enable this in the project settings:
-
-1. Go to **Settings > CI/CD**.
-1. Expand **General Pipelines**.
-1. Check the **Auto-cancel redundant pipelines** checkbox.
-1. Click **Save changes**.
-
-Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
-running job can be cancelled before it completes.
-
-## Skip outdated deployment jobs
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25276) in GitLab 12.9.
-
-Your project may have multiple concurrent deployment jobs that are
-scheduled to run in the same time frame.
-
-This can lead to a situation where an older deployment job runs after a
-newer one, which may not be what you want.
-
-To avoid this scenario:
-
-1. Go to **Settings > CI/CD**.
-1. Expand **General pipelines**.
-1. Check the **Skip outdated deployment jobs** checkbox.
-1. Click **Save changes**.
-
-When enabled, any older deployments job are skipped when a new deployment starts.
-
-For more information, see [Deployment safety](../environments/deployment_safety.md).
-
-## Retry outdated jobs
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211339) in GitLab 13.6.
-
-A deployment job can fail because a newer one has run. If you retry the failed deployment job, the
-environment could be overwritten with older source code. If you click **Retry**, a modal warns you
-about this and asks for confirmation.
-
-For more information, see [Deployment safety](../environments/deployment_safety.md).
-
 ## Pipeline Badges
 
 In the pipelines settings page you can find pipeline status and test coverage
@@ -353,6 +340,10 @@ https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text
 
 ![Badge with custom text and width](https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130)
 
+## Related topics
+
+- [Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index 355300ca9f3..687c91790ef 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -752,6 +752,7 @@ You can use CI/CD variables to customize DAST.
 | `DAST_AUTH_REPORT`                  | boolean       | Used in combination with exporting the `gl-dast-debug-auth-report.html` artifact to aid in debugging authentication issues. |
 | `DAST_AUTH_VERIFICATION_SELECTOR`   | selector      | Verifies successful authentication by checking for presence of a selector once the login form has been submitted. Example: `css:.user-photo` |
 | `DAST_AUTH_VERIFICATION_LOGIN_FORM` | boolean       | Verifies successful authentication by checking for the lack of a login form once the login form has been submitted. |
+| `DAST_ADVERTISE_SCAN`               | boolean       | Set to `true` to add a `Via` header to every request sent, advertising that the request was sent as part of a GitLab DAST scan. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/334947) in GitLab 14.1. |
 
 1. Available to an on-demand DAST scan.
 
diff --git a/doc/user/infrastructure/clusters/connect/new_gke_cluster.md b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
new file mode 100644
index 00000000000..6f695dde2e0
--- /dev/null
+++ b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
@@ -0,0 +1,94 @@
+---
+stage: Configure
+group: Configure
+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
+---
+
+# New GKE cluster through IaC
+
+Learn how to create a new cluster on Google Kubernetes Engine (GKE) through
+[Infrastructure as Code (IaC)](../../index.md).
+
+This process combines the GitLab Terraform and Google Terraform providers
+with Kubernetes to help you create GKE clusters and deploy them through
+GitLab.
+
+This document describes how to set up a [group-level cluster](../../../group/clusters/index.md) on GKE by importing an example project to get you started.
+You can then modify the project files according to your needs.
+
+**Prerequisites:**
+
+- A GitLab group.
+- A GitLab user with maintainer permissions to the group.
+- A [GitLab personal access token](../../../profile/personal_access_tokens.md) with `api` access, created by a user with maintainer permissions to the group.
+- A [Google Cloud Platform (GCP) service account](https://cloud.google.com/docs/authentication/getting-started).
+
+**Steps:**
+
+1. [Import the example project](#import-the-example-project).
+1. [Add your GCP credentials to GitLab](#add-your-gcp-credentials-to-gitlab).
+1. [Configure your project](#configure-your-project).
+1. [Deploy your cluster](#deploy-your-cluster).
+
+## Import the example project
+
+Start by [importing the example project by URL](../../../project/import/repo_by_url.md). Use `https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-gke.git` as URL.
+
+## Add your GCP credentials to GitLab
+
+After importing the project, you need to set up [CI environment variables](../../../../ci/variables/index.md) to associate your cluster on GCP to your group in GitLab.
+
+We advise that you [set environment variables through the GitLab UI](../../../../ci/variables/index.md#add-a-cicd-variable-to-a-project)
+so that your credentials are not exposed through the code. To do so, follow the steps below.
+
+### Prepare your credentials on GCP
+
+1. Create a [GCP service account](https://cloud.google.com/docs/authentication/getting-started) to authenticate GCP with GitLab. It needs the following roles: `Computer Network Viewer`, `Kubernetes Engine Admin`, and `Service Account User`.
+1. Download the JSON file with the service account key.
+1. On your computer, encode the JSON file to `base64` (replace `/path/to/sa-key.json` to the path to your key):
+
+   ```shell
+   base64 /path/to/sa-key.json | tr -d \\n`
+   ```
+
+1. Use the output of this command as the `BASE64_GOOGLE_CREDENTIALS` environment variable in the next step.
+
+### Add your credentials to GitLab as environment variables
+
+1. On GitLab, from your project's sidebar, go to **Settings > CI/CD** and expand **Variables**.
+1. Add your `GITLAB_TOKEN` ([personal access token](../../../profile/personal_access_tokens.md)).
+1. Add the variable `BASE64_GOOGLE_CREDENTIALS` from the previous step.
+
+## Configure your project
+
+After authenticating with GCP, replace the project's defaults from the example
+project with your own. To do so, edit the files as described below.
+
+Edit `gke.tf`:
+
+1. **(Required)** Replace the GCP `project` with a unique project name.
+1. **(Optional)** Choose the `name` of your cluster.
+1. **(Optional)** Choose the `region` and `zone` that you would like to deploy your cluster to.
+1. Push the changes to your project's default branch.
+
+Edit `group_cluster.tf`:
+
+1. **(Required)**: Replace the `full_path` with the path to your group.
+1. **(Optional)**: Choose your cluster base domain through `domain`.
+1. **(Optional)**: Choose your environment through `environment_scope`.
+1. Push the changes to your project's default branch.
+
+Refer to the [GitLab Terraform provider](https://registry.terraform.io/providers/gitlabhq/gitlab/latest/docs) and the [Google Terraform provider](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) documentation for further resource options.
+
+## Deploy your cluster
+
+After adjusting the files in the previous step, manually trigger the deployment of your cluster. In GitLab:
+
+1. From your project's sidebar, go to **CI/CD > Pipelines**.
+1. Select the dropdown icon (**{angle-down}**) next to the play icon (**{play}**).
+1. Select **deploy** to manually trigger the deployment job.
+
+When the pipeline finishes successfully, you can see your new cluster:
+
+- In GCP: on your [GCP console's Kubernetes list](https://console.cloud.google.com/kubernetes/list).
+- In GitLab: from your project's sidebar, select **Infrastructure > Kubernetes clusters**.
diff --git a/doc/user/infrastructure/index.md b/doc/user/infrastructure/index.md
index 9f0ced8dd58..adedee7e731 100644
--- a/doc/user/infrastructure/index.md
+++ b/doc/user/infrastructure/index.md
@@ -101,3 +101,7 @@ owned by GitLab, where everyone can contribute.
 
 The [documentation of the provider](https://registry.terraform.io/providers/gitlabhq/gitlab/latest/docs)
 is available as part of the official Terraform provider documentations.
+
+## Create a new cluster through IaC
+
+Learn how to [create a new cluster on Google Kubernetes Engine (GKE)](clusters/connect/new_gke_cluster.md).
diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md
index 90abfabb0d9..18346d7e9f7 100644
--- a/doc/user/project/merge_requests/code_quality.md
+++ b/doc/user/project/merge_requests/code_quality.md
@@ -10,17 +10,22 @@ type: reference, howto
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1984) in GitLab 9.3.
 > - Made [available in all tiers](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) in 13.2.
 
-Ensuring your project's code stays simple, readable and easy to contribute to can be problematic. With the help of [GitLab CI/CD](../../../ci/index.md), you can analyze your
-source code quality using GitLab Code Quality.
+To ensure your project's code stays simple, readable, and easy to contribute to,
+you can use [GitLab CI/CD](../../../ci/index.md) to analyze your source code quality.
+
+For example, while you're implementing a feature, you can run Code Quality reports
+to analyze how your improvements are impacting your code's quality. You can
+use this information to ensure that your changes are improving performance rather
+than degrading it.
 
 Code Quality:
 
-- Uses [Engines](https://docs.codeclimate.com/docs/list-of-engines) supported by Code Climate, which are
+- Uses [plugins](https://docs.codeclimate.com/docs/list-of-engines) supported by Code Climate, which are
   free and open source. Code Quality does not require a Code Climate
   subscription.
-- Runs in [pipelines](../../../ci/pipelines/index.md) using a Docker image built in the
-  [GitLab Code
-  Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project using [default Code Climate configurations](https://gitlab.com/gitlab-org/ci-cd/codequality/-/tree/master/codeclimate_defaults).
+- Runs in [pipelines](../../../ci/pipelines/index.md) by using a Docker image built in the
+  [GitLab Code Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project.
+- Uses [default Code Climate configurations](https://gitlab.com/gitlab-org/ci-cd/codequality/-/tree/master/codeclimate_defaults).
 - Can make use of a [template](#example-configuration).
 - Is available by using [Auto Code Quality](../../../topics/autodevops/stages.md#auto-code-quality), provided by [Auto DevOps](../../../topics/autodevops/index.md).
 - Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool).
@@ -75,21 +80,6 @@ Feature.disable(:codequality_mr_diff_annotations)
 Feature.disable(:codequality_mr_diff_annotations, Project.find(<project id>))
 ```
 
-## Use cases
-
-For instance, consider the following workflow:
-
-1. Your backend team member starts a new implementation for making a certain
-   feature in your app faster.
-1. With Code Quality reports, they analyze how their implementation is impacting
-   the code quality.
-1. The metrics show that their code degrades the quality by 10 points.
-1. You ask a co-worker to help them with this modification.
-1. They both work on the changes until Code Quality report displays no
-   degradations, only improvements.
-1. You approve the merge request and authorize its deployment to staging.
-1. Once verified, their changes are deployed to production.
-
 ## Example configuration
 
 This example shows how to run Code Quality on your code by using GitLab CI/CD and Docker.
diff --git a/doc/user/project/pages/getting_started/pages_from_scratch.md b/doc/user/project/pages/getting_started/pages_from_scratch.md
index c28233901c8..eb5f3a1bbf0 100644
--- a/doc/user/project/pages/getting_started/pages_from_scratch.md
+++ b/doc/user/project/pages/getting_started/pages_from_scratch.md
@@ -4,40 +4,54 @@ group: Release
 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
 ---
 
-# Create a GitLab Pages website from scratch **(FREE)**
+# Tutorial: Create a GitLab Pages website from scratch **(FREE)**
 
-This tutorial shows you how to create a Pages site from scratch. You start with
-a blank project and create your own CI file, which gives instruction to
-a [runner](https://docs.gitlab.com/runner/). When your CI/CD
+This tutorial shows you how to create a Pages site from scratch using
+the [Jekyll](https://jekyllrb.com/) Static Site Generator (SSG). You start with
+a blank project and create your own CI/CD configuration file, which gives
+instructions to a [runner](https://docs.gitlab.com/runner/). When your CI/CD
 [pipeline](../../../../ci/pipelines/index.md) runs, the Pages site is created.
 
-This example uses the [Jekyll](https://jekyllrb.com/) Static Site Generator (SSG).
-Other SSGs follow similar steps. You do not need to be familiar with Jekyll or SSGs
+This example uses Jekyll, but other SSGs follow similar steps.
+You do not need to be familiar with Jekyll or SSGs
 to complete this tutorial.
 
+To create a GitLab Pages website:
+
+- [Step 1: Create the project files](#create-the-project-files)
+- [Step 2: Choose a Docker image](#choose-a-docker-image)
+- [Step 3: Install Jekyll](#install-jekyll)
+- [Step 4: Specify the `public` directory for output](#specify-the-public-directory-for-output)
+- [Step 5: Specify the `public` directory for artifacts](#specify-the-public-directory-for-artifacts)
+- [Step 6: Deploy and view your website](#deploy-and-view-your-website)
+
 ## Prerequisites
 
-To follow along with this example, start with a blank project in GitLab.
-Create three files in the root (top-level) directory.
+You must have a [blank project](../../working_with_projects.md#blank-projects) in GitLab.
 
-- `.gitlab-ci.yml` A YAML file that contains the commands you want to run.
-  For now, leave the file's contents blank.
+## Create the project files
 
-- `index.html` An HTML file you can populate with whatever HTML content you'd like,
-  for example:
+Create three files in the root (top-level) directory:
 
-  ```html
-  <html>
-  <head>
-    <title>Home</title>
-  </head>
-  <body>
-    <h1>Hello World!</h1>
-  </body>
-  </html>
-  ```
+- `.gitlab-ci.yml`: A YAML file that contains the commands you want to run.
+   For now, leave the file's contents blank.
+
+- `index.html`: An HTML file you can populate with whatever HTML content
+   you'd like, for example:
+
+   ```html
+   <html>
+   <head>
+     <title>Home</title>
+   </head>
+   <body>
+     <h1>Hello World!</h1>
+   </body>
+   </html>
+   ```
+
+- [`Gemfile`](https://bundler.io/gemfile.html): A file that describes dependencies for Ruby programs.
 
-- [`Gemfile`](https://bundler.io/gemfile.html) A file that describes dependencies for Ruby programs.
   Populate it with this content:
 
   ```ruby
@@ -53,7 +67,7 @@ to run scripts and deploy the site.
 
 This specific Ruby image is maintained on [DockerHub](https://hub.docker.com/_/ruby).
 
-Edit your `.gitlab-ci.yml` and add this text as the first line.
+Edit your `.gitlab-ci.yml` file and add this text as the first line:
 
 ```yaml
 image: ruby:2.7
@@ -65,13 +79,15 @@ image that contains NodeJS as part of its file system. For example, for a
 
 ## Install Jekyll
 
-To run [Jekyll](https://jekyllrb.com/) locally, you would open your terminal and:
+To run [Jekyll](https://jekyllrb.com/) locally, you must install it:
 
-- Install [Bundler](https://bundler.io/) by running `gem install bundler`.
-- Create `Gemfile.lock` by running `bundle install`.
-- Install Jekyll by running `bundle exec jekyll build`.
+1. Open your terminal.
+1. Install [Bundler](https://bundler.io/) by running `gem install bundler`.
+1. Create `Gemfile.lock` by running `bundle install`.
+1. Install Jekyll by running `bundle exec jekyll build`.
 
-In the `.gitlab-ci.yml` file, this is written as:
+To run Jekyll in your project, edit the `.gitlab-ci.yml` file
+and add the installation commands:
 
 ```yaml
 script:
@@ -109,7 +125,8 @@ pages:
 Jekyll needs to know where to generate its output.
 GitLab Pages only considers files in a directory called `public`.
 
-Jekyll uses destination (`-d`) to specify an output directory for the built website:
+Jekyll uses a destination flag (`-d`) to specify an output directory for the built website.
+Add the destination to your `.gitlab-ci.yml` file:
 
 ```yaml
 pages:
@@ -136,7 +153,7 @@ pages:
       - public
 ```
 
-Paste this into `.gitlab-ci.yml` file, so it now looks like this:
+Your `.gitlab-ci.yml` file should now look like this:
 
 ```yaml
 image: ruby:2.7
@@ -151,23 +168,29 @@ pages:
       - public
 ```
 
-Now save and commit the `.gitlab-ci.yml` file. You can watch the pipeline run
-by going to **CI/CD > Pipelines**.
+## Deploy and view your website
 
-When it succeeds, go to **Settings > Pages** to view the URL where your site
-is now available.
+After you have completed the preceding steps,
+deploy your website:
+
+1. Save and commit the `.gitlab-ci.yml` file.
+1. Go to **CI/CD > Pipelines** to watch the pipeline.
+1. When the pipeline succeeds, go to **Settings > Pages**
+   to view the URL where your site is now available.
+
+When this `pages` job completes successfully, a special `pages:deploy` job
+appears in the pipeline view. It prepares the content of the website for the
+GitLab Pages daemon. GitLab runs it in the background and doesn't use a runner.
+
+## Other options for your CI/CD file
 
 If you want to do more advanced tasks, you can update your `.gitlab-ci.yml` file
 with [any of the available settings](../../../../ci/yaml/index.md). You can validate
 your `.gitlab-ci.yml` file with the [CI Lint](../../../../ci/lint.md) tool that's included with GitLab.
 
-After successful execution of this `pages` job, a special `pages:deploy` job appears in the
-pipeline view. It prepares the content of the website for GitLab Pages daemon. GitLab executes it in
-the background and doesn't use runner.
-
 The following topics show other examples of other options you can add to your CI/CD file.
 
-## Deploy specific branches to a Pages site
+### Deploy specific branches to a Pages site
 
 You may want to deploy to a Pages site only from specific branches.
 
@@ -191,7 +214,8 @@ pages:
       - public
 ```
 
-Then configure the pipeline to run the job for the `master` branch only.
+Then configure the pipeline to run the job for the
+[default branch](../../repository/branches/default.md) (here, `main`) only.
 
 ```yaml
 image: ruby:2.7
@@ -209,17 +233,17 @@ pages:
     paths:
       - public
   rules:
-    - if: '$CI_COMMIT_BRANCH == "master"'
+    - if: '$CI_COMMIT_BRANCH == "main"'
 ```
 
-## Specify a stage to deploy
+### Specify a stage to deploy
 
 There are three default stages for GitLab CI/CD: build, test,
 and deploy.
 
 If you want to test your script and check the built site before deploying
 to production, you can run the test exactly as it runs when you
-push to `master`.
+push to your [default branch](../../repository/branches/default.md) (here, `main`).
 
 To specify a stage for your job to run in,
 add a `stage` line to your CI file:
@@ -241,11 +265,11 @@ pages:
     paths:
       - public
   rules:
-    - if: '$CI_COMMIT_BRANCH == "master"'
+    - if: '$CI_COMMIT_BRANCH == "main"'
 ```
 
 Now add another job to the CI file, telling it to
-test every push to every branch **except** the `master` branch:
+test every push to every branch **except** the `main` branch:
 
 ```yaml
 image: ruby:2.7
@@ -264,7 +288,7 @@ pages:
     paths:
       - public
   rules:
-    - if: '$CI_COMMIT_BRANCH == "master"'
+    - if: '$CI_COMMIT_BRANCH == "main"'
 
 test:
   stage: test
@@ -276,19 +300,19 @@ test:
     paths:
       - test
   rules:
-    - if: '$CI_COMMIT_BRANCH != "master"'
+    - if: '$CI_COMMIT_BRANCH != "main"'
 ```
 
 When the `test` job runs in the `test` stage, Jekyll
 builds the site in a directory called `test`. The job affects
-all branches except `master`.
+all branches except `main`.
 
 When you apply stages to different jobs, every job in the same
 stage builds in parallel. If your web application needs more than
 one test before being deployed, you can run all your tests at the
 same time.
 
-## Remove duplicate commands
+### Remove duplicate commands
 
 To avoid duplicating the same scripts in every job, you can add them
 to a `before_script` section.
@@ -317,7 +341,7 @@ pages:
     paths:
       - public
   rules:
-    - if: '$CI_COMMIT_BRANCH == "master"'
+    - if: '$CI_COMMIT_BRANCH == "main"'
 
 test:
   stage: test
@@ -327,10 +351,10 @@ test:
     paths:
       - test
   rules:
-    - if: '$CI_COMMIT_BRANCH != "master"'
+    - if: '$CI_COMMIT_BRANCH != "main"'
 ```
 
-## Build faster with cached dependencies
+### Build faster with cached dependencies
 
 To build faster, you can cache the installation files for your
 project's dependencies by using the `cache` parameter.
@@ -361,7 +385,7 @@ pages:
     paths:
       - public
   rules:
-    - if: '$CI_COMMIT_BRANCH == "master"'
+    - if: '$CI_COMMIT_BRANCH == "main"'
 
 test:
   stage: test
@@ -371,7 +395,7 @@ test:
     paths:
       - test
   rules:
-    - if: '$CI_COMMIT_BRANCH != "master"'
+    - if: '$CI_COMMIT_BRANCH != "main"'
 ```
 
 In this case, you need to exclude the `/vendor`
@@ -386,10 +410,11 @@ exclude:
   - vendor
 ```
 
-Now GitLab CI/CD not only builds the website,
-but also pushes with **continuous tests** to feature-branches,
-**caches** dependencies installed with Bundler, and
-**continuously deploys** every push to the `master` branch.
+Now GitLab CI/CD not only builds the website, but also:
+
+- Pushes with **continuous tests** to feature branches.
+- **Caches** dependencies installed with Bundler.
+- **Continuously deploys** every push to the `main` branch.
 
 ## Related topics
 
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index ef5ae1339f6..8db8f77b650 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -35016,9 +35016,6 @@ msgstr ""
 msgid "UpdateProject|Project could not be updated!"
 msgstr ""
 
-msgid "UpdateRepositoryStorage|Error moving repository storage for %{container_full_path} - %{message}"
-msgstr ""
-
 msgid "UpdateRepositoryStorage|Failed to verify %{type} repository checksum from %{old} to %{new}"
 msgstr ""
 
diff --git a/qa/qa/runtime/env.rb b/qa/qa/runtime/env.rb
index 6ae6dbef012..bbc2fe41816 100644
--- a/qa/qa/runtime/env.rb
+++ b/qa/qa/runtime/env.rb
@@ -71,7 +71,9 @@ module QA
           ActiveSupport::Deprecation.warn("CHROME_HEADLESS is deprecated. Use WEBDRIVER_HEADLESS instead.")
         end
 
-        enabled?(ENV['WEBDRIVER_HEADLESS']) || enabled?(ENV['CHROME_HEADLESS'])
+        return enabled?(ENV['WEBDRIVER_HEADLESS']) unless ENV['WEBDRIVER_HEADLESS'].nil?
+
+        enabled?(ENV['CHROME_HEADLESS'])
       end
 
       # set to 'true' to have Chrome use a fixed profile directory
@@ -336,7 +338,7 @@ module QA
       # the feature is supported in the environment under test.
       # All features are supported by default.
       def can_test?(feature)
-        raise ArgumentError, %Q(Unknown feature "#{feature}") unless SUPPORTED_FEATURES.include? feature
+        raise ArgumentError, %(Unknown feature "#{feature}") unless SUPPORTED_FEATURES.include? feature
 
         enabled?(ENV[SUPPORTED_FEATURES[feature]], default: true)
       end
@@ -398,7 +400,9 @@ module QA
 
       def remote_grid_credentials
         if remote_grid_username
-          raise ArgumentError, %Q(Please provide an access key for user "#{remote_grid_username}") unless remote_grid_access_key
+          unless remote_grid_access_key
+            raise ArgumentError, %(Please provide an access key for user "#{remote_grid_username}")
+          end
 
           return "#{remote_grid_username}:#{remote_grid_access_key}@"
         end
diff --git a/qa/spec/runtime/env_spec.rb b/qa/spec/runtime/env_spec.rb
index ab1043842e5..1d702b70d10 100644
--- a/qa/spec/runtime/env_spec.rb
+++ b/qa/spec/runtime/env_spec.rb
@@ -55,11 +55,6 @@ RSpec.describe QA::Runtime::Env do
   end
 
   describe '.webdriver_headless?' do
-    before do
-      # We need to set this because we have a fallback for CHROME_HEADLESS
-      stub_env('CHROME_HEADLESS', 'false')
-    end
-
     it_behaves_like 'boolean method',
       method: :webdriver_headless?,
       env_key: 'WEBDRIVER_HEADLESS',
diff --git a/spec/services/projects/update_repository_storage_service_spec.rb b/spec/services/projects/update_repository_storage_service_spec.rb
index 5b15b7d5f34..17d01a57221 100644
--- a/spec/services/projects/update_repository_storage_service_spec.rb
+++ b/spec/services/projects/update_repository_storage_service_spec.rb
@@ -83,9 +83,10 @@ RSpec.describe Projects::UpdateRepositoryStorageService do
             .with(project.repository.raw)
             .and_raise(Gitlab::Git::CommandError)
 
-          result = subject.execute
+          expect do
+            subject.execute
+          end.to raise_error(Gitlab::Git::CommandError)
 
-          expect(result).to be_error
           expect(project).not_to be_repository_read_only
           expect(project.repository_storage).to eq('default')
           expect(repository_storage_move).to be_failed
@@ -101,9 +102,10 @@ RSpec.describe Projects::UpdateRepositoryStorageService do
           expect(original_project_repository_double).to receive(:remove)
             .and_raise(Gitlab::Git::CommandError)
 
-          result = subject.execute
+          expect do
+            subject.execute
+          end.to raise_error(Gitlab::Git::CommandError)
 
-          expect(result).to be_error
           expect(repository_storage_move).to be_cleanup_failed
         end
       end
@@ -118,9 +120,10 @@ RSpec.describe Projects::UpdateRepositoryStorageService do
           expect(project_repository_double).to receive(:checksum)
             .and_return('not matching checksum')
 
-          result = subject.execute
+          expect do
+            subject.execute
+          end.to raise_error(UpdateRepositoryStorageMethods::Error, /Failed to verify project repository checksum/)
 
-          expect(result).to be_error
           expect(project).not_to be_repository_read_only
           expect(project.repository_storage).to eq('default')
         end
diff --git a/spec/services/snippets/update_repository_storage_service_spec.rb b/spec/services/snippets/update_repository_storage_service_spec.rb
index 50b28a5a125..fdea3615fb1 100644
--- a/spec/services/snippets/update_repository_storage_service_spec.rb
+++ b/spec/services/snippets/update_repository_storage_service_spec.rb
@@ -75,9 +75,10 @@ RSpec.describe Snippets::UpdateRepositoryStorageService do
           .with(snippet.repository.raw)
           .and_raise(Gitlab::Git::CommandError)
 
-        result = subject.execute
+        expect do
+          subject.execute
+        end.to raise_error(Gitlab::Git::CommandError)
 
-        expect(result).to be_error
         expect(snippet).not_to be_repository_read_only
         expect(snippet.repository_storage).to eq('default')
         expect(repository_storage_move).to be_failed
@@ -93,9 +94,10 @@ RSpec.describe Snippets::UpdateRepositoryStorageService do
         expect(original_snippet_repository_double).to receive(:remove)
           .and_raise(Gitlab::Git::CommandError)
 
-        result = subject.execute
+        expect do
+          subject.execute
+        end.to raise_error(Gitlab::Git::CommandError)
 
-        expect(result).to be_error
         expect(repository_storage_move).to be_cleanup_failed
       end
     end
@@ -107,9 +109,10 @@ RSpec.describe Snippets::UpdateRepositoryStorageService do
         expect(snippet_repository_double).to receive(:checksum)
           .and_return('not matching checksum')
 
-        result = subject.execute
+        expect do
+          subject.execute
+        end.to raise_error(UpdateRepositoryStorageMethods::Error, /Failed to verify snippet repository checksum from \w+ to not matching checksum/)
 
-        expect(result).to be_error
         expect(snippet).not_to be_repository_read_only
         expect(snippet.repository_storage).to eq('default')
       end
diff --git a/spec/support/shared_examples/services/projects/update_repository_storage_service_shared_examples.rb b/spec/support/shared_examples/services/projects/update_repository_storage_service_shared_examples.rb
index 275ddebc18c..14af35e58b7 100644
--- a/spec/support/shared_examples/services/projects/update_repository_storage_service_shared_examples.rb
+++ b/spec/support/shared_examples/services/projects/update_repository_storage_service_shared_examples.rb
@@ -123,9 +123,10 @@ RSpec.shared_examples 'moves repository to another storage' do |repository_type|
         .with(repository.raw)
         .and_raise(Gitlab::Git::CommandError)
 
-      result = subject.execute
+      expect do
+        subject.execute
+      end.to raise_error(Gitlab::Git::CommandError)
 
-      expect(result).to be_error
       expect(project).not_to be_repository_read_only
       expect(project.repository_storage).to eq('default')
       expect(repository_storage_move).to be_failed
@@ -149,9 +150,10 @@ RSpec.shared_examples 'moves repository to another storage' do |repository_type|
       expect(original_repository_double).to receive(:remove)
         .and_raise(Gitlab::Git::CommandError)
 
-      result = subject.execute
+      expect do
+        subject.execute
+      end.to raise_error(Gitlab::Git::CommandError)
 
-      expect(result).to be_error
       expect(repository_storage_move).to be_cleanup_failed
     end
   end
@@ -170,9 +172,10 @@ RSpec.shared_examples 'moves repository to another storage' do |repository_type|
       allow(repository_double).to receive(:checksum)
         .and_return('not matching checksum')
 
-      result = subject.execute
+      expect do
+        subject.execute
+      end.to raise_error(UpdateRepositoryStorageMethods::Error, /Failed to verify \w+ repository checksum from \w+ to not matching checksum/)
 
-      expect(result).to be_error
       expect(project).not_to be_repository_read_only
       expect(project.repository_storage).to eq('default')
     end