diff --git a/app/assets/javascripts/vue_shared/components/markdown/header.vue b/app/assets/javascripts/vue_shared/components/markdown/header.vue
index 13189670e17..cc97933c1db 100644
--- a/app/assets/javascripts/vue_shared/components/markdown/header.vue
+++ b/app/assets/javascripts/vue_shared/components/markdown/header.vue
@@ -187,7 +187,7 @@ export default {
       <template #tabs-end>
         <div
           data-testid="md-header-toolbar"
-          :class="{ 'gl-display-none': previewMarkdown }"
+          :class="{ 'gl-display-none!': previewMarkdown }"
           class="md-header-toolbar gl-ml-auto gl-pb-3 gl-justify-content-center"
         >
           <toolbar-button
diff --git a/app/assets/stylesheets/framework/markdown_area.scss b/app/assets/stylesheets/framework/markdown_area.scss
index 7731ec751c9..7522f791b8e 100644
--- a/app/assets/stylesheets/framework/markdown_area.scss
+++ b/app/assets/stylesheets/framework/markdown_area.scss
@@ -72,7 +72,6 @@
     @include media-breakpoint-down(xs) {
       .nav-item {
         flex: 1;
-        border-bottom: 1px solid $border-color;
       }
 
       .gl-tab-nav-item {
@@ -84,7 +83,8 @@
         width: 100%;
         display: flex;
         flex-wrap: wrap;
-        margin-top: $gl-padding-8;
+        padding-top: $gl-padding-8;
+        border-top: 1px solid $border-color;
       }
     }
   }
diff --git a/app/views/groups/_import_group_from_another_instance_panel.html.haml b/app/views/groups/_import_group_from_another_instance_panel.html.haml
index 5b9cd80799c..a08728f282a 100644
--- a/app/views/groups/_import_group_from_another_instance_panel.html.haml
+++ b/app/views/groups/_import_group_from_another_instance_panel.html.haml
@@ -4,8 +4,9 @@
       %h4.gl-display-flex
         = s_('GroupsNew|Import groups from another instance of GitLab')
       = link_to _('History'), history_import_bulk_imports_path, class: 'gl-link gl-ml-auto'
-    .gl-alert.gl-alert-warning{ role: 'alert' }
-      = sprite_icon('warning', css_class: 'gl-icon s16 gl-alert-icon gl-alert-icon-no-title')
+    = render 'shared/global_alert',
+      dismissible: false,
+      variant: :warning do
       .gl-alert-body
         - docs_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: help_page_path('user/group/import/index.md') }
         - docs_link_end = '</a>'.html_safe
diff --git a/config/routes.rb b/config/routes.rb
index ef9e21282fd..92fc9025e98 100644
--- a/config/routes.rb
+++ b/config/routes.rb
@@ -66,6 +66,7 @@ Rails.application.routes.draw do
     end
 
     Gitlab.ee do
+      resources :company, only: [:new]
       resources :groups, only: [:new, :create]
       resources :projects, only: [:new, :create]
       resources :groups_projects, only: [:new, :create] do
diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt
index 6dc0704963b..b277158e963 100644
--- a/doc/.vale/gitlab/spelling-exceptions.txt
+++ b/doc/.vale/gitlab/spelling-exceptions.txt
@@ -594,6 +594,7 @@ Sobelow
 Solargraph
 Solarized
 Sourcegraph
+spammable
 sparkline
 sparklines
 spidering
diff --git a/doc/administration/compliance.md b/doc/administration/compliance.md
index 7c3f36c71c2..99c291379f1 100644
--- a/doc/administration/compliance.md
+++ b/doc/administration/compliance.md
@@ -82,7 +82,7 @@ These features can help provide visibility into GitLab and audit what is happeni
 
 These features can also help with compliance requirements:
 
-- [**Email all users of a project, group, or entire server**](../tools/email.md)
+- [**Email all users of a project, group, or entire server**](../user/admin_area/email_from_gitlab.md)
   (for instances): An administrator can email groups of users based on project
   or group membership, or email everyone using the GitLab instance. These emails
   are great for scheduled maintenance or upgrades.
diff --git a/doc/administration/geo/replication/version_specific_updates.md b/doc/administration/geo/replication/version_specific_updates.md
index 95833a290dd..d3bc54775f4 100644
--- a/doc/administration/geo/replication/version_specific_updates.md
+++ b/doc/administration/geo/replication/version_specific_updates.md
@@ -10,6 +10,14 @@ Review this page for update instructions for your version. These steps
 accompany the [general steps](updating_the_geo_sites.md#general-update-steps)
 for updating Geo sites.
 
+## Updating to 14.9
+
+**DO NOT** update to GitLab 14.9.0. 
+
+We've discovered an issue with Geo's CI verification feature that may [cause job traces to be lost](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6664). This issue will be fixed in the next patch release.
+
+If you have already updated to GitLab 14.9.0, you can disable the feature causing the issue by [disabling the `geo_job_artifact_replication` feature flag](../../feature_flags.md#how-to-enable-and-disable-features-behind-flags).
+
 ## Updating to 14.2 through 14.7
 
 There is [an issue in GitLab 14.2 through 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/299819#note_822629467)
diff --git a/doc/administration/index.md b/doc/administration/index.md
index ec586b22bea..89d1f2ce2eb 100644
--- a/doc/administration/index.md
+++ b/doc/administration/index.md
@@ -126,7 +126,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
   - [Sync LDAP](auth/ldap/index.md)
   - [Kerberos authentication](../integration/kerberos.md)
   - See also other [authentication](../topics/authentication/index.md#gitlab-administrators) topics (for example, enforcing 2FA).
-- [Email users](../tools/email.md): Email GitLab users from GitLab.
+- [Email users](../user/admin_area/email_from_gitlab.md): Email GitLab users from GitLab.
 - [User Cohorts](../user/admin_area/user_cohorts.md): Display the monthly cohorts of new users and their activities over time.
 - [Audit events](audit_events.md): View the changes made on the GitLab server for:
   - Groups and projects.
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 7bf7362c68b..d6f5588ebc9 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -903,6 +903,10 @@ You can also [run cleanup on a schedule](../../user/packages/container_registry/
 
 ## Container Registry garbage collection
 
+NOTE:
+Retention policies within your object storage provider, such as Amazon S3 Lifecycle, may prevent
+objects from being properly deleted.
+
 Container Registry can use considerable amounts of disk space. To clear up
 some unused layers, the registry includes a garbage collect command.
 
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index d66f3b1ed35..82ebdcaab42 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -183,9 +183,12 @@ Redis version >= 2.0.0? ... yes
 Checking GitLab ... Finished
 ```
 
-## Rebuild authorized_keys file
+## Rebuild `authorized_keys` file
 
-In some case it is necessary to rebuild the `authorized_keys` file. To do this, run:
+In some cases it is necessary to rebuild the `authorized_keys` file,
+for example, if after an upgrade you receive `Permission denied (publickey)` when pushing [via SSH](../../ssh/index.md)
+and find `404 Key Not Found` errors in [the `gitlab-shell.log` file](../logs.md#gitlab-shelllog).
+To rebuild `authorized_keys`, run:
 
 **Omnibus Installation**
 
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index f82f23cca7d..1fed63c3706 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -1455,10 +1455,12 @@ To configure the Praefect nodes, on each one:
 ### Configure Gitaly
 
 The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
-requirements that are dependent on data, specifically the number of projects
-and those projects' sizes. It's recommended that a Gitaly Cluster stores
-no more than 5 TB of data on each node. Depending on your
-repository storage requirements, you may require additional Gitaly Clusters.
+requirements that are dependent on data and load.
+
+NOTE:
+The Reference Architecture specs have been designed with good headroom in mind
+but for Gitaly, increased specs or additional
+Gitaly Cluster arrays may be required for notably large data sets or load.
 
 Due to Gitaly having notable input and output requirements, we strongly
 recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 6d56f67097b..cabb3c16366 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -1459,10 +1459,12 @@ the file of the same name on this server. If this is the first Omnibus node you
 ### Configure Gitaly
 
 The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
-requirements that are dependent on data, specifically the number of projects
-and those projects' sizes. It's recommended that a Gitaly Cluster stores
-no more than 5 TB of data on each node. Depending on your
-repository storage requirements, you may require additional Gitaly Clusters.
+requirements that are dependent on data and load.
+
+NOTE:
+The Reference Architecture specs have been designed with good headroom in mind
+but for Gitaly, increased specs or additional
+Gitaly Cluster arrays may be required for notably large data sets or load.
 
 Due to Gitaly having notable input and output requirements, we strongly
 recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index 6f6c02c309a..f9a7420c0bc 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -397,11 +397,13 @@ are supported and can be added if needed.
 
 ## Configure Gitaly
 
-[Gitaly](../gitaly/index.md) server node requirements are dependent on data,
-specifically the number of projects and those projects' sizes. It's recommended
-that a Gitaly server node stores no more than 5TB of data. Although this
-reference architecture includes a single Gitaly server node, you may require
-additional nodes depending on your repository storage requirements.
+[Gitaly](../gitaly/index.md) server node requirements are dependent on data size,
+specifically the number of projects and those projects' sizes.
+
+NOTE:
+The Reference Architecture specs have been designed with good headroom in mind
+but for Gitaly, increased specs or switching to Gitaly Cluster
+may be required for notably large data sets or load.
 
 Due to Gitaly having notable input and output requirements, we strongly
 recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index ec6204c21a1..081ed9d2be5 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -1399,10 +1399,12 @@ the file of the same name on this server. If this is the first Omnibus node you
 ### Configure Gitaly
 
 The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
-requirements that are dependent on data, specifically the number of projects
-and those projects' sizes. It's recommended that a Gitaly Cluster stores
-no more than 5 TB of data on each node. Depending on your
-repository storage requirements, you may require additional Gitaly Clusters.
+requirements that are dependent on data and load.
+
+NOTE:
+The Reference Architecture specs have been designed with good headroom in mind
+but for Gitaly, increased specs or additional
+Gitaly Cluster arrays may be required for notably large data sets or load.
 
 Due to Gitaly having notable input and output requirements, we strongly
 recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
@@ -2157,6 +2159,7 @@ but with smaller performance requirements, several modifications can be consider
 - Reducing the node counts: Some node types do not need consensus and can run with fewer nodes (but more than one for redundancy). This will also lead to reduced performance.
   - GitLab Rails and Sidekiq: Stateless services don't have a minimum node count. Two are enough for redundancy.
   - Gitaly and Praefect: A quorum is not strictly necessary. Two Gitaly nodes and two Praefect nodes are enough for redundancy.
+  - PostgreSQL and PgBouncer: A quorum is not strictly necessary. Two PostgreSQL nodes and two PgBouncer nodes are enough for redundancy.
 - Running select components in reputable Cloud PaaS solutions: Select components of the GitLab setup can instead be run on Cloud Provider PaaS solutions. By doing this, additional dependent components can also be removed:
   - PostgreSQL: Can be run on reputable Cloud PaaS solutions such as Google Cloud SQL or Amazon RDS. In this setup, the PgBouncer and Consul nodes are no longer required:
     - Consul may still be desired if [Prometheus](../monitoring/prometheus/index.md) auto discovery is a requirement, otherwise you would need to [manually add scrape configurations](../monitoring/prometheus/index.md#adding-custom-scrape-configurations) for all nodes.
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index 9ff4e8e53c4..84ec20e308a 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -1468,10 +1468,12 @@ the file of the same name on this server. If this is the first Omnibus node you
 ### Configure Gitaly
 
 The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
-requirements that are dependent on data, specifically the number of projects
-and those projects' sizes. It's recommended that a Gitaly Cluster stores
-no more than 5 TB of data on each node. Depending on your
-repository storage requirements, you may require additional Gitaly Clusters.
+requirements that are dependent on data and load.
+
+NOTE:
+The Reference Architecture specs have been designed with good headroom in mind
+but for Gitaly, increased specs or additional
+Gitaly Cluster arrays may be required for notably large data sets or load.
 
 Due to Gitaly having notable input and output requirements, we strongly
 recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 50b5bbd6dc8..a88eb402ecd 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -1397,10 +1397,12 @@ the file of the same name on this server. If this is the first Omnibus node you
 ### Configure Gitaly
 
 The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
-requirements that are dependent on data, specifically the number of projects
-and those projects' sizes. It's recommended that a Gitaly Cluster stores
-no more than 5 TB of data on each node. Depending on your
-repository storage requirements, you may require additional Gitaly Clusters.
+requirements that are dependent on data and load.
+
+NOTE:
+The Reference Architecture specs have been designed with good headroom in mind
+but for Gitaly, increased specs or additional
+Gitaly Cluster arrays may be required for notably large data sets or load.
 
 Due to Gitaly having notable input and output requirements, we strongly
 recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index d1ab2cb0d79..02a1fe8176a 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -11043,7 +11043,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 
 ##### `GeoNode.jobArtifactRegistries`
 
-Find Job Artifact registries on this Geo node.
+Find Job Artifact registries on this Geo node Available only when feature flag `geo_job_artifact_replication` is enabled. This flag is disabled by default, because the feature is experimental and is subject to change without notice.
 
 Returns [`JobArtifactRegistryConnection`](#jobartifactregistryconnection).
 
diff --git a/doc/api/index.md b/doc/api/index.md
index 178c2f05a6d..f78a501fb11 100644
--- a/doc/api/index.md
+++ b/doc/api/index.md
@@ -150,6 +150,10 @@ message with a status code of `401`:
 }
 ```
 
+NOTE:
+Deploy tokens can't be used with the GitLab public API. For details, see
+[Deploy Tokens](../user/project/deploy_tokens/index.md).
+
 ### OAuth2 tokens
 
 You can use an [OAuth2 token](oauth2.md) to authenticate with the API by passing
diff --git a/doc/development/service_ping/index.md b/doc/development/service_ping/index.md
index 6878fd1bf28..1db3c409151 100644
--- a/doc/development/service_ping/index.md
+++ b/doc/development/service_ping/index.md
@@ -76,7 +76,7 @@ tier. Users can continue to access the features in a paid tier without sharing u
 
 #### Features available in 14.1 and later
 
-1. [Email from GitLab](../../tools/email.md).
+1. [Email from GitLab](../../user/admin_area/email_from_gitlab.md).
 
 #### Features available in 14.4 and later
 
diff --git a/doc/development/spam_protection_and_captcha/graphql_api.md b/doc/development/spam_protection_and_captcha/graphql_api.md
index b47e3f84320..e3f4e9069e5 100644
--- a/doc/development/spam_protection_and_captcha/graphql_api.md
+++ b/doc/development/spam_protection_and_captcha/graphql_api.md
@@ -13,28 +13,27 @@ related to changing a model's confidential/public flag.
 
 ## Add support to the GraphQL mutations
 
-This implementation is very similar to the controller implementation. You create a `spam_params`
-instance based on the request, and pass it to the relevant Service class constructor.
+The main steps are:
 
-The three main differences from the controller implementation are:
+1. Use `include Mutations::SpamProtection` in your mutation.
+1. Create a `spam_params` instance based on the request. Obtain the request from the context
+   via `context[:request]` when creating the `SpamParams` instance.
+1. Pass `spam_params` to the relevant Service class constructor.
+1. After you create or update the `Spammable` model instance, call `#check_spam_action_response!`
+   and pass it the model instance. This call:
+   1. Performs the necessary spam checks on the model.
+   1. If spam is detected:
+      - Raises a `GraphQL::ExecutionError` exception.
+      - Includes the relevant information added as error fields to the response via the `extensions:` parameter.
+        For more details on these fields, refer to the section in the GraphQL API documentation on
+        [Resolve mutations detected as spam](../../api/graphql/index.md#resolve-mutations-detected-as-spam).
 
-1. Use `include Mutations::SpamProtection` instead of `...JsonFormatActionsSupport`.
-1. Obtain the request from the context via `context[:request]` when creating the `SpamParams`
-   instance.
-1. After you create or updated the `Spammable` model instance, call `#check_spam_action_response!`
-   and pass it the model instance. This call will:
-    1. Perform the necessary spam checks on the model.
-    1. If spam is detected:
-       - Raise a `GraphQL::ExecutionError` exception.
-       - Include the relevant information added as error fields to the response via the `extensions:` parameter.
-       For more details on these fields, refer to the section on
-       [Spam and CAPTCHA support in the GraphQL API](../../api/graphql/index.md#resolve-mutations-detected-as-spam).
-
-       NOTE:
-       If you use the standard ApolloLink or Axios interceptor CAPTCHA support described
-       above, the field details are unimportant. They become important if you
-       attempt to use the GraphQL API directly to process a failed check for potential spam, and
-       resubmit the request with a solved CAPTCHA response.
+   NOTE:
+   If you use the standard ApolloLink or Axios interceptor CAPTCHA support described
+   above, you can ignore the field details, because they are handled
+   automatically. They become relevant if you attempt to use the GraphQL API directly to
+   process a failed check for potential spam, and resubmit the request with a solved
+   CAPTCHA response.
 
 For example:
 
@@ -57,10 +56,13 @@ module Mutations
         widget = service_response.payload[:widget]
         check_spam_action_response!(widget)
 
-        # If possible spam wasdetected, an exception would have been thrown by
+        # If possible spam was detected, an exception would have been thrown by
         # `#check_spam_action_response!`, so the normal resolve return logic can follow below.
       end
     end
   end
 end
 ```
+
+Refer to the [Exploratory Testing](exploratory_testing.md) section for instructions on how to test
+CAPTCHA behavior in the GraphQL API.
diff --git a/doc/development/spam_protection_and_captcha/index.md b/doc/development/spam_protection_and_captcha/index.md
index 9b195df536d..dbe8c4aa4e9 100644
--- a/doc/development/spam_protection_and_captcha/index.md
+++ b/doc/development/spam_protection_and_captcha/index.md
@@ -16,7 +16,7 @@ To add this support, you must implement the following areas as applicable:
 1. [Model and Services](model_and_services.md): The basic prerequisite
    changes to the backend code which are required to add spam or CAPTCHA API and UI support
    for a feature which does not yet have support.
-1. REST API (Supported, documentation coming soon): The changes needed to add
+1. [REST API](rest_api.md): The changes needed to add
    spam or CAPTCHA support to Grape REST API endpoints. Refer to the related
    [REST API documentation](../../api/index.md#resolve-requests-detected-as-spam).
 1. [GraphQL API](graphql_api.md): The changes needed to add spam or CAPTCHA support to GraphQL
diff --git a/doc/development/spam_protection_and_captcha/rest_api.md b/doc/development/spam_protection_and_captcha/rest_api.md
new file mode 100644
index 00000000000..ad74977eb67
--- /dev/null
+++ b/doc/development/spam_protection_and_captcha/rest_api.md
@@ -0,0 +1,90 @@
+---
+stage: Manage
+group: Authentication and Authorization
+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
+---
+
+# REST API spam protection and CAPTCHA support
+
+If the model can be modified via the REST API, you must also add support to all of the
+relevant API endpoints which may modify spammable or spam-related attributes. This
+definitely includes the `POST` and `PUT` mutations, but may also include others, such as those
+related to changing a model's confidential/public flag.
+
+## Add support to the REST endpoints
+
+The main steps are:
+
+1. Add `helpers SpammableActions::CaptchaCheck::RestApiActionsSupport` in your `resource`.
+1. Create a `spam_params` instance based on the request.
+1. Pass `spam_params` to the relevant Service class constructor.
+1. After you create or update the `Spammable` model instance, call `#check_spam_action_response!`,
+   save the created or updated instance in a variable.
+1. Identify the error handling logic for the `failure` case of the request,
+   when create or update was not successful. These indicate possible spam detection,
+   which adds an error to the `Spammable` instance.
+   The error is usually similar to `render_api_error!` or `render_validation_error!`.
+1. Wrap the existing error handling logic in a
+   `with_captcha_check_rest_api(spammable: my_spammable_instance)` call, passing the `Spammable`
+   model instance you saved in a variable as the `spammable:` named argument. This call will:
+   1. Perform the necessary spam checks on the model.
+   1. If spam is detected:
+      - Raise a Grape `#error!` exception with a descriptive spam-specific error message.
+      - Include the relevant information added as error fields to the response.
+        For more details on these fields, refer to the section in the REST API documentation on
+        [Resolve requests detected as spam](../../api/index.md#resolve-requests-detected-as-spam).
+
+   NOTE:
+   If you use the standard ApolloLink or Axios interceptor CAPTCHA support described
+   above, you can ignore the field details, because they are handled
+   automatically. They become relevant if you attempt to use the GraphQL API directly to
+   process a failed check for potential spam, and resubmit the request with a solved
+   CAPTCHA response.
+
+Here is an example for the `post` and `put` actions on the `snippets` resource:
+
+```ruby
+module API
+  class Snippets < ::API::Base
+    #...
+    resource :snippets do
+      # This helper provides `#with_captcha_check_rest_api`
+      helpers SpammableActions::CaptchaCheck::RestApiActionsSupport
+
+      post do
+        #...
+        spam_params = ::Spam::SpamParams.new_from_request(request: request)
+        service_response = ::Snippets::CreateService.new(project: nil, current_user: current_user, params: attrs, spam_params: spam_params).execute
+        snippet = service_response.payload[:snippet]
+
+        if service_response.success?
+          present snippet, with: Entities::PersonalSnippet, current_user: current_user
+        else
+          # Wrap the normal error response in a `with_captcha_check_rest_api(spammable: snippet)` block
+          with_captcha_check_rest_api(spammable: snippet) do
+            # If possible spam was detected, an exception would have been thrown by
+            # `#with_captcha_check_rest_api` for Grape to handle via `error!`
+            render_api_error!({ error: service_response.message }, service_response.http_status)
+          end
+        end
+      end
+
+      put ':id' do
+        #...
+        spam_params = ::Spam::SpamParams.new_from_request(request: request)
+        service_response = ::Snippets::UpdateService.new(project: nil, current_user: current_user, params: attrs, spam_params: spam_params).execute(snippet)
+
+        snippet = service_response.payload[:snippet]
+
+        if service_response.success?
+          present snippet, with: Entities::PersonalSnippet, current_user: current_user
+        else
+          # Wrap the normal error response in a `with_captcha_check_rest_api(spammable: snippet)` block
+          with_captcha_check_rest_api(spammable: snippet) do
+            # If possible spam was detected, an exception would have been thrown by
+            # `#with_captcha_check_rest_api` for Grape to handle via `error!`
+            render_api_error!({ error: service_response.message }, service_response.http_status)
+          end
+        end
+      end
+```
diff --git a/doc/development/spam_protection_and_captcha/web_ui.md b/doc/development/spam_protection_and_captcha/web_ui.md
index 6aa01f401bd..9aeb9e96d44 100644
--- a/doc/development/spam_protection_and_captcha/web_ui.md
+++ b/doc/development/spam_protection_and_captcha/web_ui.md
@@ -37,7 +37,7 @@ additional fields being added to the models. Instead, communication is handled:
 The spam and CAPTCHA-related logic is also cleanly abstracted into reusable modules and helper methods
 which can wrap existing logic, and only alter the existing flow if potential spam
 is detected or a CAPTCHA display is needed. This approach allows the spam and CAPTCHA
-support to be easily added to new areas of the application with minimal changes to
+support to be added to new areas of the application with minimal changes to
 existing logic. In the case of the frontend, potentially **zero** changes are needed!
 
 On the frontend, this is handled abstractly and transparently using `ApolloLink` for Apollo, and an
@@ -75,7 +75,7 @@ sequenceDiagram
 The backend is also cleanly abstracted via mixin modules and helper methods. The three main
 changes required to the relevant backend controller actions (normally just `create`/`update`) are:
 
-1. Create a `SpamParams` parameter object instance based on the request, using the simple static
+1. Create a `SpamParams` parameter object instance based on the request, using the static
    `#new_from_request` factory method. This method takes a request, and returns a `SpamParams` instance.
 1. Pass the created `SpamParams` instance as the `spam_params` named argument to the
    Service class constructor, which you should have already added. If the spam check indicates
diff --git a/doc/subscriptions/bronze_starter.md b/doc/subscriptions/bronze_starter.md
index 7ca3a3ffade..17eafb7633e 100644
--- a/doc/subscriptions/bronze_starter.md
+++ b/doc/subscriptions/bronze_starter.md
@@ -21,7 +21,7 @@ the tiers are no longer mentioned in GitLab documentation:
 - [Code owners](../user/project/code_owners.md)
 - Description templates:
   - [Setting a default template for merge requests and issues](../user/project/description_templates.md#set-a-default-template-for-merge-requests-and-issues)
-- [Email from GitLab](../tools/email.md)
+- [Email from GitLab](../user/admin_area/email_from_gitlab.md)
 - Groups:
   - [Creating group memberships via CN](../user/group/index.md#create-group-links-via-cn)
   - [Group push rules](../user/group/index.md#group-push-rules)
diff --git a/doc/tools/email.md b/doc/tools/email.md
index 0a3e37719a4..1d46a63bae4 100644
--- a/doc/tools/email.md
+++ b/doc/tools/email.md
@@ -1,60 +1,11 @@
 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: howto, reference
+redirect_to: '../user/admin_area/email_from_gitlab.md'
+remove_date: '2022-06-18'
 ---
 
-# Email from GitLab **(PREMIUM SELF)**
+This document was moved to [another location](../user/admin_area/email_from_gitlab.md).
 
-GitLab provides a tool to administrators for emailing all users, or users of
-a chosen group or project, right from the Admin Area. Users receive the email
-at their primary email address.
-
-For information about email notifications originating from GitLab, read
-[GitLab notification emails](../user/profile/notifications.md).
-
-## Use-cases
-
-- Notify your users about a new project, a new feature, or a new product launch.
-- Notify your users about a new deployment, or that downtime is expected
-  for a particular reason.
-
-## Sending emails to users from within GitLab
-
-1. On the top bar, select **Menu > Admin**.
-1. On the left sidebar, select **Overview > Users**.
-1. Select **Send email to users**.
-
-   ![administrators](email1.png)
-
-1. Compose an email and choose where to send it (all users or users of a
-   chosen group or project). The email body only supports plain text messages.
-   HTML, Markdown, and other rich text formats are not supported, and is
-   sent as plain text to users.
-
-   ![compose an email](email2.png)
-
-NOTE:
-[Starting with GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/31509), email notifications can be sent only once every 10 minutes. This helps minimize performance issues.
-
-## Unsubscribing from emails
-
-Users can choose to unsubscribe from receiving emails from GitLab by following
-the unsubscribe link in the email. Unsubscribing is unauthenticated in order
-to keep this feature simple.
-
-On unsubscribe, users receive an email notification that unsubscribe happened.
-The endpoint that provides the unsubscribe option is rate-limited.
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+<!-- This redirect file can be deleted after <2022-06-18>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/admin_area/email_from_gitlab.md b/doc/user/admin_area/email_from_gitlab.md
new file mode 100644
index 00000000000..52f27ed48e0
--- /dev/null
+++ b/doc/user/admin_area/email_from_gitlab.md
@@ -0,0 +1,60 @@
+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+type: howto, reference
+---
+
+# Email from GitLab **(PREMIUM SELF)**
+
+GitLab provides a tool to administrators for emailing all users, or users of
+a chosen group or project, right from the Admin Area. Users receive the email
+at their primary email address.
+
+For information about email notifications originating from GitLab, read
+[GitLab notification emails](../profile/notifications.md).
+
+## Use-cases
+
+- Notify your users about a new project, a new feature, or a new product launch.
+- Notify your users about a new deployment, or that downtime is expected
+  for a particular reason.
+
+## Sending emails to users from GitLab
+
+1. On the top bar, select **Menu > Admin**.
+1. On the left sidebar, select **Overview > Users**.
+1. Select **Send email to users**.
+
+   ![administrators](img/email1.png)
+
+1. Compose an email and choose where to send it (all users or users of a
+   chosen group or project). The email body only supports plain text messages.
+   HTML, Markdown, and other rich text formats are not supported, and is
+   sent as plain text to users.
+
+   ![compose an email](img/email2.png)
+
+NOTE:
+[Starting with GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/31509), email notifications can be sent only once every 10 minutes. This helps minimize performance issues.
+
+## Unsubscribing from emails
+
+Users can choose to unsubscribe from receiving emails from GitLab by following
+the unsubscribe link in the email. Unsubscribing is unauthenticated in order
+to keep this feature simple.
+
+On unsubscribe, users receive an email notification that unsubscribe happened.
+The endpoint that provides the unsubscribe option is rate-limited.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/tools/email1.png b/doc/user/admin_area/img/email1.png
similarity index 100%
rename from doc/tools/email1.png
rename to doc/user/admin_area/img/email1.png
diff --git a/doc/tools/email2.png b/doc/user/admin_area/img/email2.png
similarity index 100%
rename from doc/tools/email2.png
rename to doc/user/admin_area/img/email2.png
diff --git a/doc/user/packages/dependency_proxy/index.md b/doc/user/packages/dependency_proxy/index.md
index e431d4d7de3..735932642a7 100644
--- a/doc/user/packages/dependency_proxy/index.md
+++ b/doc/user/packages/dependency_proxy/index.md
@@ -132,7 +132,8 @@ There are other additional predefined CI/CD variables you can also use:
 - `CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX`: the image prefix for pulling images through the
   dependency proxy from the direct group or subgroup that the project belongs to.
 
-`CI_DEPENDENCY_PROXY_SERVER` and `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`
+`CI_DEPENDENCY_PROXY_SERVER`, `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`, and
+`CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX`
 include the server port. If you explicitly include the Dependency Proxy
 path, the port must be included, unless you have logged into the Dependency
 Proxy manually without including the port:
diff --git a/doc/user/profile/notifications.md b/doc/user/profile/notifications.md
index ca85fd7be05..c5460a31701 100644
--- a/doc/user/profile/notifications.md
+++ b/doc/user/profile/notifications.md
@@ -11,7 +11,7 @@ Stay informed about what's happening in GitLab with email notifications.
 You can receive updates about activity in issues, merge requests, epics, and designs.
 
 For the tool that GitLab administrators can use to send messages to users, read
-[Email from GitLab](../../tools/email.md).
+[Email from GitLab](../admin_area/email_from_gitlab.md).
 
 ## Who receives notifications
 
@@ -308,7 +308,7 @@ If you no longer wish to receive any email notifications:
    **Disabled**.
 
 On self-managed installations, even after doing this, your instance administrator
-[can still email you](../../tools/email.md).
+[can still email you](../admin_area/email_from_gitlab.md).
 To unsubscribe, select the unsubscribe link in one of these emails.
 
 ## Email headers you can use to filter email
diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md
index 4d69209aafa..64c18ab6f3b 100644
--- a/doc/user/project/deploy_tokens/index.md
+++ b/doc/user/project/deploy_tokens/index.md
@@ -16,7 +16,9 @@ container registry images of a project without having a user and a password.
 
 Deploy tokens can be managed only by users with the Maintainer role.
 
-Deploy tokens cannot be used with the GitLab API.
+Deploy tokens can't be used with the GitLab public API. However, you can use deploy tokens with some
+endpoints, such as those from the Package Registry. For details, see
+[Authenticate with the registry](../../packages/package_registry/index.md#authenticate-with-the-registry).
 
 Deploy tokens are tied to the project and stay enabled even when the user who created the token is removed from the project.
 
diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md
index 3b5e847e6cb..aa9ed1ecbad 100644
--- a/doc/user/project/settings/import_export.md
+++ b/doc/user/project/settings/import_export.md
@@ -383,3 +383,17 @@ s = Gitlab::ImportExport::Saver.new(exportable: p, shared:p.import_export_shared
 s.send(:compress_and_save)
 s.send(:save_upload)
 ```
+
+### Import using the REST API fails when using a group access token
+
+[Group access tokens](../../group/settings/group_access_tokens.md)
+don't work for project or group import operations. When a group access token initiates an import,
+the import fails with this message:
+
+```plaintext
+Error adding importer user to Project members.
+Validation failed: User project bots cannot be added to other groups / projects
+```
+
+To use [Import REST APIs](../../../api/project_import_export.md),
+pass regular user account credentials such as [personal access tokens](../../profile/personal_access_tokens.md).
diff --git a/lib/gitlab/ci/status/build/manual.rb b/lib/gitlab/ci/status/build/manual.rb
index df572188194..0074f3675e0 100644
--- a/lib/gitlab/ci/status/build/manual.rb
+++ b/lib/gitlab/ci/status/build/manual.rb
@@ -5,20 +5,36 @@ module Gitlab
     module Status
       module Build
         class Manual < Status::Extended
+          def self.matches?(build, user)
+            build.playable?
+          end
+
           def illustration
             {
               image: 'illustrations/manual_action.svg',
               size: 'svg-394',
               title: _('This job requires a manual action'),
-              content: _('This job requires manual intervention to start. Before starting this job, you can add variables below for last-minute configuration changes.')
+              content: illustration_content
             }
           end
 
-          def self.matches?(build, user)
-            build.playable?
+          private
+
+          def illustration_content
+            if can?(user, :update_build, subject)
+              _('This job requires manual intervention to start. Before starting this job, you can add variables below for last-minute configuration changes.')
+            else
+              generic_permission_failure_message
+            end
+          end
+
+          def generic_permission_failure_message
+            _("This job does not run automatically and must be started manually, but you do not have access to it.")
           end
         end
       end
     end
   end
 end
+
+Gitlab::Ci::Status::Build::Manual.prepend_mod_with('Gitlab::Ci::Status::Build::Manual')
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 11035e9a230..aea718dab5c 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -1811,6 +1811,9 @@ msgstr ""
 msgid "About this feature"
 msgstr ""
 
+msgid "About your company"
+msgstr ""
+
 msgid "Abuse Reports"
 msgstr ""
 
@@ -16782,6 +16785,9 @@ msgstr ""
 msgid "GitLab Team Member"
 msgstr ""
 
+msgid "GitLab Ultimate trial"
+msgstr ""
+
 msgid "GitLab User"
 msgstr ""
 
@@ -37976,6 +37982,9 @@ msgstr ""
 msgid "This deployment is not waiting for approvals."
 msgstr ""
 
+msgid "This deployment job does not run automatically and must be started manually, but you do not have access to this job's protected environment. The job can only be started by a project member allowed to deploy to the environment."
+msgstr ""
+
 msgid "This device has already been registered with us."
 msgstr ""
 
@@ -38138,6 +38147,9 @@ msgstr ""
 msgid "This job does not have a trace."
 msgstr ""
 
+msgid "This job does not run automatically and must be started manually, but you do not have access to it."
+msgstr ""
+
 msgid "This job has been canceled"
 msgstr ""
 
@@ -39432,6 +39444,9 @@ msgstr ""
 msgid "Try again?"
 msgstr ""
 
+msgid "Try all GitLab features for free for 30 days. No credit card required."
+msgstr ""
+
 msgid "Try all GitLab has to offer for 30 days."
 msgstr ""
 
@@ -41874,6 +41889,9 @@ msgstr ""
 msgid "Webhooks|Wiki page events"
 msgstr ""
 
+msgid "Website"
+msgstr ""
+
 msgid "Website:"
 msgstr ""
 
diff --git a/spec/frontend/vue_shared/components/markdown/header_spec.js b/spec/frontend/vue_shared/components/markdown/header_spec.js
index 9ffb9c6a541..fa4ca63f910 100644
--- a/spec/frontend/vue_shared/components/markdown/header_spec.js
+++ b/spec/frontend/vue_shared/components/markdown/header_spec.js
@@ -95,7 +95,7 @@ describe('Markdown field header component', () => {
   it('hides toolbar in preview mode', () => {
     createWrapper({ previewMarkdown: true });
 
-    expect(findToolbar().classes().includes('gl-display-none')).toBe(true);
+    expect(findToolbar().classes().includes('gl-display-none!')).toBe(true);
   });
 
   it('emits toggle markdown event when clicking preview tab', async () => {
diff --git a/spec/lib/gitlab/ci/status/build/manual_spec.rb b/spec/lib/gitlab/ci/status/build/manual_spec.rb
index 78193055139..150705c1e36 100644
--- a/spec/lib/gitlab/ci/status/build/manual_spec.rb
+++ b/spec/lib/gitlab/ci/status/build/manual_spec.rb
@@ -3,15 +3,27 @@
 require 'spec_helper'
 
 RSpec.describe Gitlab::Ci::Status::Build::Manual do
-  let(:user) { create(:user) }
+  let_it_be(:user) { create(:user) }
+  let_it_be(:job) { create(:ci_build, :manual) }
 
   subject do
-    build = create(:ci_build, :manual)
-    described_class.new(Gitlab::Ci::Status::Core.new(build, user))
+    described_class.new(Gitlab::Ci::Status::Core.new(job, user))
   end
 
   describe '#illustration' do
     it { expect(subject.illustration).to include(:image, :size, :title, :content) }
+
+    context 'when the user can trigger the job' do
+      before do
+        job.project.add_maintainer(user)
+      end
+
+      it { expect(subject.illustration[:content]).to match /This job requires manual intervention to start/ }
+    end
+
+    context 'when the user can not trigger the job' do
+      it { expect(subject.illustration[:content]).to match /This job does not run automatically and must be started manually/ }
+    end
   end
 
   describe '.matches?' do