Add latest changes from gitlab-org/gitlab@master

20 files changed, 168 insertions, 135 deletions

diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt
index 58a42871ae5..3e0bc041e4f 100644
--- a/doc/.vale/gitlab/spelling-exceptions.txt
+++ b/doc/.vale/gitlab/spelling-exceptions.txt
@@ -208,6 +208,7 @@ formatters
 Fugit
 fuzzer
 Gantt
+Gemfile
 Gemnasium
 Gemojione
 Getter
diff --git a/doc/api/commits.md b/doc/api/commits.md
index 8feea5fa9c2..a2d13ec5166 100644
--- a/doc/api/commits.md
+++ b/doc/api/commits.md
@@ -305,6 +305,7 @@ Parameters:
 | `sha` | string | yes | The commit hash  |
 | `branch` | string | yes | The name of the branch  |
 | `dry_run` | boolean | no | Does not commit any changes. Default is false. [Introduced in GitLab 13.3](https://gitlab.com/gitlab-org/gitlab/-/issues/231032) |
+| `message` | string | no | A custom commit message to use for the new commit. [Introduced in GitLab 14.0](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62481)
 
 ```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form "branch=master" "https://gitlab.example.com/api/v4/projects/5/repository/commits/master/cherry_pick"
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 240a6c02a97..1b356fea17c 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -11933,6 +11933,17 @@ Represents rules that commit pushes must follow.
 | ---- | ---- | ----------- |
 | <a id="pushrulesrejectunsignedcommits"></a>`rejectUnsignedCommits` | [`Boolean!`](#boolean) | Indicates whether commits not signed through GPG will be rejected. |
 
+### `PypiMetadata`
+
+Pypi metadata.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="pypimetadataid"></a>`id` | [`PackagesPypiMetadatumID!`](#packagespypimetadatumid) | ID of the metadatum. |
+| <a id="pypimetadatarequiredpython"></a>`requiredPython` | [`String`](#string) | Required Python version of the Pypi package. |
+
 ### `RecentFailures`
 
 Recent failure history of a test case.
@@ -15298,6 +15309,12 @@ A `PackagesPackageID` is a global ID. It is encoded as a string.
 
 An example `PackagesPackageID` is: `"gid://gitlab/Packages::Package/1"`.
 
+### `PackagesPypiMetadatumID`
+
+A `PackagesPypiMetadatumID` is a global ID. It is encoded as a string.
+
+An example `PackagesPypiMetadatumID` is: `"gid://gitlab/Packages::Pypi::Metadatum/1"`.
+
 ### `PathLockID`
 
 A `PathLockID` is a global ID. It is encoded as a string.
@@ -15429,6 +15446,7 @@ One of:
 - [`ConanMetadata`](#conanmetadata)
 - [`MavenMetadata`](#mavenmetadata)
 - [`NugetMetadata`](#nugetmetadata)
+- [`PypiMetadata`](#pypimetadata)
 
 #### `VulnerabilityDetail`
 
diff --git a/doc/api/jobs.md b/doc/api/jobs.md
index 2dee909aa44..c2994bb4254 100644
--- a/doc/api/jobs.md
+++ b/doc/api/jobs.md
@@ -63,11 +63,11 @@ Example of response
     "pipeline": {
       "id": 6,
       "project_id": 1,
-      "ref": "master",
+      "ref": "main",
       "sha": "0ff3ae198f8601a285adcf5c0fff204ee6fba5fd",
       "status": "pending"
     },
-    "ref": "master",
+    "ref": "main",
     "runner": null,
     "stage": "test",
     "status": "failed",
@@ -117,11 +117,11 @@ Example of response
     "pipeline": {
       "id": 6,
       "project_id": 1,
-      "ref": "master",
+      "ref": "main",
       "sha": "0ff3ae198f8601a285adcf5c0fff204ee6fba5fd",
       "status": "pending"
     },
-    "ref": "master",
+    "ref": "main",
     "artifacts": [],
     "runner": null,
     "stage": "test",
@@ -198,11 +198,11 @@ Example of response
     "pipeline": {
       "id": 6,
       "project_id": 1,
-      "ref": "master",
+      "ref": "main",
       "sha": "0ff3ae198f8601a285adcf5c0fff204ee6fba5fd",
       "status": "pending"
     },
-    "ref": "master",
+    "ref": "main",
     "artifacts": [],
     "runner": null,
     "stage": "test",
@@ -263,11 +263,11 @@ Example of response
     "pipeline": {
       "id": 6,
       "project_id": 1,
-      "ref": "master",
+      "ref": "main",
       "sha": "0ff3ae198f8601a285adcf5c0fff204ee6fba5fd",
       "status": "pending"
     },
-    "ref": "master",
+    "ref": "main",
     "runner": null,
     "stage": "test",
     "status": "failed",
@@ -348,14 +348,14 @@ Example of response
     "pipeline": {
       "id": 6,
       "project_id": 1,
-      "ref": "master",
+      "ref": "main",
       "sha": "0ff3ae198f8601a285adcf5c0fff204ee6fba5fd",
       "status": "pending",
       "created_at": "2015-12-24T15:50:16.123Z",
       "updated_at": "2015-12-24T18:00:44.432Z",
       "web_url": "https://example.com/foo/bar/pipelines/6"
     },
-    "ref": "master",
+    "ref": "main",
     "stage": "test",
     "status": "pending",
     "tag": false,
@@ -380,7 +380,7 @@ Example of response
     "downstream_pipeline": {
       "id": 5,
       "sha": "f62a4b2fb89754372a346f24659212eb8da13601",
-      "ref": "master",
+      "ref": "main",
       "status": "pending",
       "created_at": "2015-12-24T17:54:27.722Z",
       "updated_at": "2015-12-24T17:58:27.896Z",
@@ -433,11 +433,11 @@ Example of response
   "pipeline": {
     "id": 6,
     "project_id": 1,
-    "ref": "master",
+    "ref": "main",
     "sha": "0ff3ae198f8601a285adcf5c0fff204ee6fba5fd",
     "status": "pending"
   },
-  "ref": "master",
+  "ref": "main",
   "artifacts": [],
   "runner": null,
   "stage": "test",
@@ -518,7 +518,7 @@ Example response:
     "id": 1,
     "project_id": 1,
     "sha": "b83d6e391c22777fca1ed3012fce84f633d7fed0",
-    "ref": "master",
+    "ref": "main",
     "status": "pending",
     "created_at": "2021-03-26T14:51:51.107Z",
     "updated_at": "2021-03-26T14:51:51.107Z",
@@ -590,11 +590,11 @@ Example of response
   "pipeline": {
     "id": 6,
     "project_id": 1,
-    "ref": "master",
+    "ref": "main",
     "sha": "0ff3ae198f8601a285adcf5c0fff204ee6fba5fd",
     "status": "pending"
   },
-  "ref": "master",
+  "ref": "main",
   "artifacts": [],
   "runner": null,
   "stage": "test",
@@ -684,7 +684,7 @@ Example of response
   "queued_duration": 0.010,
   "id": 42,
   "name": "rubocop",
-  "ref": "master",
+  "ref": "main",
   "artifacts": [],
   "runner": null,
   "stage": "test",
@@ -734,7 +734,7 @@ Example of response
   "queued_duration": 0.010,
   "id": 42,
   "name": "rubocop",
-  "ref": "master",
+  "ref": "main",
   "artifacts": [],
   "runner": null,
   "stage": "test",
@@ -784,7 +784,7 @@ Example of response
   "download_url": null,
   "id": 42,
   "name": "rubocop",
-  "ref": "master",
+  "ref": "main",
   "artifacts": [],
   "runner": null,
   "stage": "test",
@@ -839,7 +839,7 @@ Example of response
   "queued_duration": 0.010,
   "id": 42,
   "name": "rubocop",
-  "ref": "master",
+  "ref": "main",
   "artifacts": [],
   "runner": null,
   "stage": "test",
diff --git a/doc/api/pipeline_schedules.md b/doc/api/pipeline_schedules.md
index e6d2e190df9..6f9f81e9766 100644
--- a/doc/api/pipeline_schedules.md
+++ b/doc/api/pipeline_schedules.md
@@ -30,7 +30,7 @@ curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/a
     {
         "id": 13,
         "description": "Test schedule pipeline",
-        "ref": "master",
+        "ref": "main",
         "cron": "* * * * *",
         "cron_timezone": "Asia/Tokyo",
         "next_run_at": "2017-05-19T13:41:00.000Z",
@@ -70,7 +70,7 @@ curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/a
 {
     "id": 13,
     "description": "Test schedule pipeline",
-    "ref": "master",
+    "ref": "main",
     "cron": "* * * * *",
     "cron_timezone": "Asia/Tokyo",
     "next_run_at": "2017-05-19T13:41:00.000Z",
@@ -80,7 +80,7 @@ curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/a
     "last_pipeline": {
         "id": 332,
         "sha": "0e788619d0b5ec17388dffb973ecd505946156db",
-        "ref": "master",
+        "ref": "main",
         "status": "pending"
     },
     "owner": {
@@ -119,14 +119,14 @@ POST /projects/:id/pipeline_schedules
 | `active`        | boolean        | no       | The activation of pipeline schedule. If false is set, the pipeline schedule is initially deactivated (default: `true`). |
 
 ```shell
-curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form description="Build packages" --form ref="master" --form cron="0 1 * * 5" --form cron_timezone="UTC" --form active="true" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules"
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form description="Build packages" --form ref="main" --form cron="0 1 * * 5" --form cron_timezone="UTC" --form active="true" "https://gitlab.example.com/api/v4/projects/29/pipeline_schedules"
 ```
 
 ```json
 {
     "id": 14,
     "description": "Build packages",
-    "ref": "master",
+    "ref": "main",
     "cron": "0 1 * * 5",
     "cron_timezone": "UTC",
     "next_run_at": "2017-05-26T01:00:00.000Z",
@@ -171,7 +171,7 @@ curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --form cron="0
 {
     "id": 13,
     "description": "Test schedule pipeline",
-    "ref": "master",
+    "ref": "main",
     "cron": "0 2 * * *",
     "cron_timezone": "Asia/Tokyo",
     "next_run_at": "2017-05-19T17:00:00.000Z",
@@ -181,7 +181,7 @@ curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --form cron="0
     "last_pipeline": {
         "id": 332,
         "sha": "0e788619d0b5ec17388dffb973ecd505946156db",
-        "ref": "master",
+        "ref": "main",
         "status": "pending"
     },
     "owner": {
@@ -216,7 +216,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitla
 {
     "id": 13,
     "description": "Test schedule pipeline",
-    "ref": "master",
+    "ref": "main",
     "cron": "0 2 * * *",
     "cron_timezone": "Asia/Tokyo",
     "next_run_at": "2017-05-19T17:00:00.000Z",
@@ -226,7 +226,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitla
     "last_pipeline": {
         "id": 332,
         "sha": "0e788619d0b5ec17388dffb973ecd505946156db",
-        "ref": "master",
+        "ref": "main",
         "status": "pending"
     },
     "owner": {
@@ -261,7 +261,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://git
 {
     "id": 13,
     "description": "Test schedule pipeline",
-    "ref": "master",
+    "ref": "main",
     "cron": "0 2 * * *",
     "cron_timezone": "Asia/Tokyo",
     "next_run_at": "2017-05-19T17:00:00.000Z",
@@ -271,7 +271,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://git
     "last_pipeline": {
         "id": 332,
         "sha": "0e788619d0b5ec17388dffb973ecd505946156db",
-        "ref": "master",
+        "ref": "main",
         "status": "pending"
     },
     "owner": {
diff --git a/doc/api/pipelines.md b/doc/api/pipelines.md
index 1e1d21f73a6..a40e8e35171 100644
--- a/doc/api/pipelines.md
+++ b/doc/api/pipelines.md
@@ -99,7 +99,7 @@ Example of response
   "id": 46,
   "project_id": 1,
   "status": "success",
-  "ref": "master",
+  "ref": "main",
   "sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
   "before_sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
   "tag": false,
@@ -226,7 +226,7 @@ POST /projects/:id/pipeline
 | `variables` | array   | no       | An array containing the variables available in the pipeline, matching the structure `[{ 'key': 'UPLOAD_TO_S3', 'variable_type': 'file', 'value': 'true' }]` |
 
 ```shell
-curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/pipeline?ref=master"
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/pipeline?ref=main"
 ```
 
 Example of response
@@ -236,7 +236,7 @@ Example of response
   "id": 61,
   "project_id": 1,
   "sha": "384c444e840a515b23f21915ee5766b87068a70d",
-  "ref": "master",
+  "ref": "main",
   "status": "pending",
   "before_sha": "0000000000000000000000000000000000000000",
   "tag": false,
@@ -285,7 +285,7 @@ Response:
   "id": 46,
   "project_id": 1,
   "status": "pending",
-  "ref": "master",
+  "ref": "main",
   "sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
   "before_sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
   "tag": false,
@@ -334,7 +334,7 @@ Response:
   "id": 46,
   "project_id": 1,
   "status": "canceled",
-  "ref": "master",
+  "ref": "main",
   "sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
   "before_sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
   "tag": false,
diff --git a/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md b/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md
index 69661aa2be0..92717dc1fe9 100644
--- a/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md
+++ b/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md
@@ -30,7 +30,7 @@ and allow us to have much better resiliency and much easier way to scale applica
 
 The actual split was tested with the usage of [Rails Engines](https://guides.rubyonrails.org/engines.html)
 implementing separate gems in a single repository. The [Rails Engines](https://guides.rubyonrails.org/engines.html)
-allowed us to well describe the indivdual components with its dependencies and run an application
+allowed us to well describe the individual components with its dependencies and run an application
 consisting of many Rails Engines.
 
 The blueprint aims to retain all key aspects of GitLab success: single and monolithic codebase (with a [single data-store](https://about.gitlab.com/handbook/product/single-application/#single-data-store)),
@@ -52,7 +52,7 @@ codebase without clear boundaries results in a number of problems and inefficien
 - The high memory usage results in slowing the whole application as it increases GC cycles duration
   creating significantly longer latency for processing requests or worse cache usage of CPUs
 - Increased application boot-up times as we need to load and parse significantly more files
-- Longer boot-up times slows down the development, as running application or tests takes singificantly longer
+- Longer boot-up times slows down the development, as running application or tests takes significantly longer
   reducing velocity and amount of iterations
 
 ## Composable codebase dimensions
@@ -123,8 +123,8 @@ application layers. This list is not exhaustive, but shows a general list of the
 - Services/Models/DB: all code required to maintain our database structure, data validation, business logic and policies models that needs to be shared with other components
 
 The best way to likely describe how the actual GitLab Rails split would look like. It is a satellite model.
-Where we have a single core, that is shared across all satelitte components. The design of that implies
-that satelitte components have a limited way to communicate with each other. In a single monolithic application
+Where we have a single core, that is shared across all satellite components. The design of that implies
+that satellite components have a limited way to communicate with each other. In a single monolithic application
 in most of cases application would communicate with a code. In a satellite model the communication needs
 to be performed externally to the component. This can be via Database, Redis or using a well defined exposed API.
 
@@ -293,7 +293,7 @@ This allowed us to run Web Nodes with all dependencies, but measure the impact o
 All work can be found in these merge requests:
 
 - [Provide mechanism to load GraphQL with all dependencies only when needed](https://gitlab.com/gitlab-org/gitlab/-/issues/288044)
-- [Draft: PoC - Move Graphql to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50180)
+- [Draft: PoC - Move GraphQL to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50180)
 - [Draft: PoC - Move Controllers and Grape API:API to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53720)
 - [Draft: PoC - Move only Grape API:API to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53982)
 - [Measure performance impact for proposed web_engine](https://gitlab.com/gitlab-org/gitlab/-/issues/300548)
@@ -310,20 +310,20 @@ What was done?
 
 #### Implementation details for proposed solution
 
-1. Introduce new Rails Engine for each application layer. 
+1. Introduce new Rails Engine for each application layer.
 
     We created `engines` folder, which could contain different engines for each application layer we introduce in the future.
 
-    In the above PoCs we introuced the new Web Application Layer, located in `engines/web_engine` folder.
+    In the above PoCs we introduced the new Web Application Layer, located in `engines/web_engine` folder.
 
 1. Move all code and specs into `engines/web_engine/`
 
-    - We moved all Graphql code and specs into `engines/web_engine/` without changing files itself
+    - We moved all GraphQL code and specs into `engines/web_engine/` without changing files itself
     - We moved all Grape API and Controllers code into `engines/web_engine/` without changing files itself
 
 1. Move gems to the `engines/web_engine/`
 
-    - We moved all Graphql gems to the actual web_engine Gemfile
+    - We moved all GraphQL gems to the actual web_engine Gemfile
     - We moved Grape API gem to the actual web_engine Gemfile
 
     ```ruby
@@ -331,7 +331,7 @@ What was done?
       spec.add_dependency 'apollo_upload_server'
       spec.add_dependency 'graphql'
       spec.add_dependency 'graphiql-rails'
-    
+
       spec.add_dependency 'graphql-docs'
       spec.add_dependency 'grape'
     end
@@ -339,31 +339,31 @@ What was done?
 
 1. Move routes to the `engines/web_engine/config/routes.rb` file
 
-    - We moved Graphql routes to the web_engine routes.
+    - We moved GraphQL routes to the web_engine routes.
     - We moved API routes to the web_engine routes.
     - We moved most of the controller routes to the web_engine routes.
 
     ```ruby
     Rails.application.routes.draw do
       post '/api/graphql', to: 'graphql#execute'
-      mount GraphiQL::Rails::Engine, at: '/-/graphql-explorer', graphql_path: 
+      mount GraphiQL::Rails::Engine, at: '/-/graphql-explorer', graphql_path:
       Gitlab::Utils.append_path(Gitlab.config.gitlab.relative_url_root, '/api/graphql')
-    
+
       draw :api
-    
+
       #...
     end
     ```
 
 1. Move initializers to the `engines/web_engine/config/initializers` folder
 
-    - We moved graphql.rb initializer to the `web_engine` initializers folder
-    - We moved grape_patch.rb and graphe_validators to the `web_engine` initializers folder
+    - We moved `graphql.rb` initializer to the `web_engine` initializers folder
+    - We moved `grape_patch.rb` and `graphe_validators` to the `web_engine` initializers folder
 
 1. Connect GitLab application with the WebEngine
 
     In GitLab Gemfile.rb, add web_engine to the engines group
-  
+
     ```ruby
     # Gemfile
     group :engines, :test do
@@ -376,7 +376,7 @@ What was done?
 1. Configure GitLab when to load the engine.
 
     In GitLab `config/engines.rb`, we can configure when do we want to load our engines by relying on our `Gitlab::Runtime`
-  
+
     ```ruby
     # config/engines.rb
     # Load only in case we are running web_server or rails console
@@ -392,11 +392,11 @@ What was done?
     the application, performing tasks such as adding the app directory of the engine to
     the load path for models, mailers, controllers, and views.
     A file at `lib/web_engine/engine.rb`, is identical in function to a standard Rails
-    application's `config/application.rb` file. This way engines can access a config
+    application's `config/application.rb` file. This way engines can access a configuration
     object which contains configuration shared by all railties and the application.
-    Additionally, each engine can access autoload_paths, eager_load_paths, and autoload_once_paths
+    Additionally, each engine can access `autoload_paths`, `eager_load_paths`, and `autoload_once_paths`
     settings which are scoped to that engine.
-  
+
     ```ruby
     module WebEngine
       class Engine < ::Rails::Engine
@@ -404,7 +404,7 @@ What was done?
                                          #{config.root}/app/graphql/resolvers/concerns
                                          #{config.root}/app/graphql/mutations/concerns
                                          #{config.root}/app/graphql/types/concerns])
-    
+
         if Gitlab.ee?
           ee_paths = config.eager_load_paths.each_with_object([]) do |path, memo|
             ee_path = config.root
@@ -422,11 +422,11 @@ What was done?
 
     We adapted CI to test `engines/web_engine/` as a self-sufficient component of stack.
 
-    - We moved spec as-is files to the `engines/web_engine/spec` folder 
-    - We moved ee/spec as-is files to the `engines/web_engine/ee/spec` folder
+    - We moved `spec` as-is files to the `engines/web_engine/spec` folder
+    - We moved `ee/spec` as-is files to the `engines/web_engine/ee/spec` folder
     - We control specs from main application using environment variable `TEST_WEB_ENGINE`
-    - We added new CI job that will run `engines/web_engine/spec` tests separately using `TEST_WEB_ENGINE` env variable.
-    - We added new CI job that will run `engines/web_engine/ee/spec` tests separately using `TEST_WEB_ENGINE` env variable.
+    - We added new CI job that will run `engines/web_engine/spec` tests separately using `TEST_WEB_ENGINE` environment variable.
+    - We added new CI job that will run `engines/web_engine/ee/spec` tests separately using `TEST_WEB_ENGINE` environment variable.
     - We are running all whitebox frontend tests with `TEST_WEB_ENGINE=true`
 
 #### Results
@@ -482,12 +482,12 @@ Pros:
 
 - Significantly lower memory usage
 - Significantly shorter application load time for Sidekiq
-- Significantly improved responsivness of Sidekiq service due to much shorter GC cycles
+- Significantly improved responsiveness of Sidekiq service due to much shorter GC cycles
 - Significantly easier testing of a portion of application, ex. changing `web_engines/` does require
   re-running test only for this application layer
 - We retained a monolithic architecture of the codebase, but sharing database and application models
-- A significant saving from the infrastracture side
-- Ability to comfortably run on constrainted environments by reducing application footprint
+- A significant saving from the infrastructure side
+- Ability to comfortably run on constrained environments by reducing application footprint
 
 Cons:
 
@@ -497,7 +497,7 @@ Cons:
 
 #### Example: GraphQL
 
-[Draft: PoC - Move Graphql to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50180)
+[Draft: PoC - Move GraphQL to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50180)
 
 - The [99% of changes](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50180/diffs?commit_id=49c9881c6696eb620dccac71532a3173f5702ea8) as visible in the above MRs is moving files as-is.
 - The [actual work](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50180/diffs?commit_id=1d9a9edfa29ea6638e7d8a6712ddf09f5be77a44) on fixing cross-dependencies, specs, and configuring web_engine
@@ -506,8 +506,8 @@ Cons:
 Today, loading GraphQL requires a bunch of [dependencies](https://gitlab.com/gitlab-org/gitlab/-/issues/288044):
 
 > We also discovered that we load/require 14480 files, [memory-team-2gb-week#9](https://gitlab.com/gitlab-org/memory-team/memory-team-2gb-week/-/issues/9#note_452530513)
-> when we start GitLab. 1274 files belong to Graphql. This means that if we don't load 1274 application files
-> and all related Graphql gems when we don't need them (Sidekiq), we could save a lot of memory.
+> when we start GitLab. 1274 files belong to GraphQL. This means that if we don't load 1274 application files
+> and all related GraphQL gems when we don't need them (Sidekiq), we could save a lot of memory.
 
 GraphQL only needs to run in a specific context. If we could limit when it is being loaded we could effectively improve application efficiency, by reducing application load time and required memory. This, for example, is applicable for every size installation.
 
@@ -524,9 +524,9 @@ An alternative way is to use a notification system that would always make an `Ac
 
 Grape::API is another example that only needs to run only in a web server context.
 
-Potential chalenges with Grape API:
+Potential challenges with Grape API:
 
-- Currently there are some API::API dependencies in the models (e.g. `API::Helpers::Version` dependency in [project model](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/project.rb#L2019) or API::API dependency in GeoNode model for [geo_retrieve_url](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/geo_node.rb#L183))
+- Currently there are some API::API dependencies in the models (e.g. `API::Helpers::Version` dependency in [project model](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/project.rb#L2019) or API::API dependency in GeoNode model for [`geo_retrieve_url`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/geo_node.rb#L183))
 - `api_v4` paths are used in helpers, presenters, and views (e.g. `api_v4_projects_path` in [PackagesHelper](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/helpers/packages_helper.rb#L17))
 
 #### Example: Controllers
@@ -538,7 +538,7 @@ Potential chalenges with Grape API:
 
 Controllers, Serializers, some presenters and some of the Grape:Entities are also good examples that only need to be run in web server context.
 
-Potential chalenges with moving Controllers:
+Potential challenges with moving Controllers:
 
 - We needed to extend `Gitlab::Patch::DrawRoute` in order to support `engines/web_engine/config/routes` and `engines/web_engine/ee/config/routes` in case when `web_engine` is loaded. Here is potential [solution](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53720#note_506957398).
 - `Gitlab::Routing.url_helpers` paths are used in models and services, that could be used by Sidekiq (e.g. `Gitlab::Routing.url_helpers.project_pipelines_path` is used by [ExpirePipelineCacheService](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/expire_pipeline_cache_service.rb#L20) in [ExpirePipelineCacheWorker](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/expire_pipeline_cache_worker.rb#L18)))
@@ -552,7 +552,7 @@ Packwerk is currently accepting bug fixes only, and it is not being actively dev
 
 **Application Layers** and this proposal currently defines only `web_engine`. Following the same pattern we could easily introduce
 additional engines dedicated for supporting that would allow us to maintain much better separation, lower memory usage
-and much better maintanability of GitLab Rails into the future.
+and much better maintainability of GitLab Rails into the future.
 
 This would be a framework for introducing all new interfaces for features that do not need to be part of the core codebase,
 like support for additional Package services. Allowing us to better scale application in the future, but retaining a single codebase
@@ -564,7 +564,7 @@ As of today, it seems reasonable to define three **application layers**:
 - `gitlab-web`: a Controllers/API/GraphQL/ActionCable functionality needed to run in a web server context (depends on `gitlab-core`)
 - `gitlab-sidekiq`: a background jobs functionality needed to run Sidekiq Workers (depends on `gitlab-core`)
 
-This model is best described today as a shared core with satellite. The shared core defines data access layer, where as satellites define a way to present and process this data. Satelites can only talk with Core. They cannot directly load or talk to another satelitte unless they use a well defined interface in form of API, GraphQL or Redis (as for scheduling Sidekiq jobs).
+This model is best described today as a shared core with satellite. The shared core defines data access layer, where as satellites define a way to present and process this data. Satellites can only talk with Core. They cannot directly load or talk to another satellite unless they use a well defined interface in form of API, GraphQL or Redis (as for scheduling Sidekiq jobs).
 
 It is reasonable to assume that we limit how many `engines` we allow. Initial proposal is to allow up to 5 engines
 to be created to ensure that we do not have explosion of engines.
@@ -573,7 +573,7 @@ to be created to ensure that we do not have explosion of engines.
 
 - [Split application into functional parts to ensure that only needed code is loaded with all dependencies](https://gitlab.com/gitlab-org/gitlab/-/issues/290935)
 - [Provide mechanism to load GraphQL with all dependencies only when needed](https://gitlab.com/gitlab-org/gitlab/-/issues/288044)
-- [Draft: PoC - Move Graphql to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50180)
+- [Draft: PoC - Move GraphQL to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50180)
 - [Draft: PoC - Move Controllers and Grape API:API to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53720)
 - [Draft: PoC - Move only Grape API:API to the WebEngine](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53982)
 - [Measure performance impact for proposed web_engine](https://gitlab.com/gitlab-org/gitlab/-/issues/300548)
diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
index 4192dc1356e..5f08f2954f5 100644
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@@ -78,7 +78,7 @@ git init
 git remote add origin git@gitlab.example.com:<USERNAME>/laravel-sample.git
 git add .
 git commit -m 'Initial Commit'
-git push -u origin master
+git push -u origin main
 ```
 
 ## Configure the production server
@@ -260,7 +260,7 @@ Let's create these three tasks one by one.
 
 #### Clone the repository
 
-The first task will create the `releases` directory (if it doesn't exist), and then clone the `master` branch of the repository (by default) into the new release directory, given by the `$new_release_dir` variable.
+The first task will create the `releases` directory (if it doesn't exist), and then clone the `main` branch of the repository (by default) into the new release directory, given by the `$new_release_dir` variable.
 The `releases` directory will hold all our deployments:
 
 ```php
@@ -378,14 +378,14 @@ These are persistent data and will be shared to every new release.
 
 Now, we would need to deploy our app by running `envoy run deploy`, but it won't be necessary since GitLab can handle that for us with CI's [environments](../../environments/index.md), which will be described [later](#setting-up-gitlab-cicd) in this tutorial.
 
-Now it's time to commit [Envoy.blade.php](https://gitlab.com/mehranrasulian/laravel-sample/blob/master/Envoy.blade.php) and push it to the `master` branch.
-To keep things simple, we commit directly to `master`, without using [feature-branches](../../../topics/gitlab_flow.md#github-flow-as-a-simpler-alternative) since collaboration is beyond the scope of this tutorial.
+Now it's time to commit [Envoy.blade.php](https://gitlab.com/mehranrasulian/laravel-sample/blob/master/Envoy.blade.php) and push it to the `main` branch.
+To keep things simple, we commit directly to `main`, without using [feature-branches](../../../topics/gitlab_flow.md#github-flow-as-a-simpler-alternative) since collaboration is beyond the scope of this tutorial.
 In a real world project, teams may use [Issue Tracker](../../../user/project/issues/index.md) and [Merge Requests](../../../user/project/merge_requests/index.md) to move their code across branches:
 
 ```shell
 git add Envoy.blade.php
 git commit -m 'Add Envoy'
-git push origin master
+git push origin main
 ```
 
 ## Continuous Integration with GitLab
@@ -474,7 +474,7 @@ Let's commit the `Dockerfile` file.
 ```shell
 git add Dockerfile
 git commit -m 'Add Dockerfile'
-git push origin master
+git push origin main
 ```
 
 ### Setting up GitLab CI/CD
@@ -523,7 +523,7 @@ deploy_production:
     url: http://192.168.1.1
   when: manual
   only:
-    - master
+    - main
 ```
 
 That's a lot to take in, isn't it? Let's run through it step by step.
@@ -595,7 +595,7 @@ If the SSH keys have added successfully, we can run Envoy.
 As mentioned before, GitLab supports [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) methods as well.
 The [environment](../../yaml/README.md#environment) keyword tells GitLab that this job deploys to the `production` environment.
 The `url` keyword is used to generate a link to our application on the GitLab Environments page.
-The `only` keyword tells GitLab CI/CD that the job should be executed only when the pipeline is building the `master` branch.
+The `only` keyword tells GitLab CI/CD that the job should be executed only when the pipeline is building the `main` branch.
 Lastly, `when: manual` is used to turn the job from running automatically to a manual action.
 
 ```yaml
@@ -616,7 +616,7 @@ deploy_production:
     url: http://192.168.1.1
   when: manual
   only:
-    - master
+    - main
 ```
 
 You may also want to add another job for [staging environment](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/), to final test your application before deploying to production.
@@ -624,7 +624,7 @@ You may also want to add another job for [staging environment](https://about.git
 ### Turn on GitLab CI/CD
 
 We have prepared everything we need to test and deploy our app with GitLab CI/CD.
-To do that, commit and push `.gitlab-ci.yml` to the `master` branch. It will trigger a pipeline, which you can watch live under your project's **Pipelines**.
+To do that, commit and push `.gitlab-ci.yml` to the `main` branch. It will trigger a pipeline, which you can watch live under your project's **Pipelines**.
 
 ![pipelines page](img/pipelines_page.png)
 
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index 31677846890..734ec4b5193 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -82,7 +82,7 @@ job1:
     - echo This rule uses parentheses.
   only:
     variables:
-      - ($CI_COMMIT_BRANCH == "master" || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE
+      - ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE
 ```
 
 ### `only:changes` / `except:changes` examples
diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md
index cb5ba7fd359..15b0403bcc0 100644
--- a/doc/ci/merge_request_pipelines/index.md
+++ b/doc/ci/merge_request_pipelines/index.md
@@ -70,7 +70,7 @@ build:
   stage: build
   script: ./build
   only:
-    - master
+    - main
 
 test:
   stage: test
@@ -82,7 +82,7 @@ deploy:
   stage: deploy
   script: ./deploy
   only:
-    - master
+    - main
 ```
 
 #### Excluding certain jobs
@@ -103,7 +103,7 @@ To achieve this, you can configure your `.gitlab-ci.yml` file as follows:
 ``` yaml
 .only-default: &only-default
   only:
-    - master
+    - main
     - merge_requests
     - tags
 
diff --git a/doc/ci/migration/circleci.md b/doc/ci/migration/circleci.md
index ba67ec0d0d1..53aeec21199 100644
--- a/doc/ci/migration/circleci.md
+++ b/doc/ci/migration/circleci.md
@@ -209,7 +209,7 @@ jobs:
   deploy:
     branches:
       only:
-        - master
+        - main
         - /rc-.*/
 ```
 
@@ -221,7 +221,7 @@ deploy_prod:
   script:
     - echo "Deploy to production server"
   rules:
-    - if: '$CI_COMMIT_BRANCH == "master"'
+    - if: '$CI_COMMIT_BRANCH == "main"'
 ```
 
 ### Caching
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 76742ef9be3..0c7aaee4939 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -318,7 +318,7 @@ Markdown code embeds the test coverage report badge of the `coverage` job
 into your `README.md`:
 
 ```markdown
-![coverage](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage)
+![coverage](https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=coverage)
 ```
 
 ### Badge styles
@@ -331,7 +331,7 @@ Pipeline badges can be rendered in different styles by adding the `style=style_n
   https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat
   ```
 
-  ![Badge flat style](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage&style=flat)
+  ![Badge flat style](https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=coverage&style=flat)
 
 - Flat square ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/30120) in GitLab 11.8):
 
@@ -339,7 +339,7 @@ Pipeline badges can be rendered in different styles by adding the `style=style_n
   https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square
   ```
 
-  ![Badge flat square style](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage&style=flat-square)
+  ![Badge flat square style](https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=coverage&style=flat-square)
 
 ### Custom badge text
 
@@ -348,10 +348,10 @@ Pipeline badges can be rendered in different styles by adding the `style=style_n
 The text for a badge can be customized to differentiate between multiple coverage jobs that run in the same pipeline. Customize the badge text and width by adding the `key_text=custom_text` and `key_width=custom_key_width` parameters to the URL:
 
 ```plaintext
-https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130
+https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130
 ```
 
-![Badge with custom text and width](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130)
+![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)
 
 <!-- ## Troubleshooting
 
diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md
index e6b86ff651d..4976756dff9 100644
--- a/doc/ci/triggers/README.md
+++ b/doc/ci/triggers/README.md
@@ -56,7 +56,7 @@ and it creates a dependent pipeline relation visible on the
 trigger_pipeline:
   stage: deploy
   script:
-    - curl --request POST --form "token=$CI_JOB_TOKEN" --form ref=master "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
+    - curl --request POST --form "token=$CI_JOB_TOKEN" --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
   only:
     - tags
 ```
@@ -81,7 +81,7 @@ build_submodule:
   stage: test
   script:
     - apt update && apt install -y unzip
-    - curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/download?job=test&job_token=$CI_JOB_TOKEN"
+    - curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test&job_token=$CI_JOB_TOKEN"
     - unzip artifacts.zip
   only:
     - tags
@@ -178,7 +178,7 @@ To trigger a job from a webhook of another project you need to add the following
 webhook URL for Push and Tag events (change the project ID, ref and token):
 
 ```plaintext
-https://gitlab.example.com/api/v4/projects/9/ref/master/trigger/pipeline?token=TOKEN
+https://gitlab.example.com/api/v4/projects/9/ref/main/trigger/pipeline?token=TOKEN
 ```
 
 You should pass `ref` as part of the URL, to take precedence over `ref` from
@@ -250,7 +250,7 @@ and the script of the `upload_package` job is run:
 ```shell
 curl --request POST \
   --form token=TOKEN \
-  --form ref=master \
+  --form ref=main \
   --form "variables[UPLOAD_TO_S3]=true" \
   "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
 ```
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
index 639786ada77..bc8435afefd 100644
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
@@ -434,7 +434,7 @@ Example job log output:
 export CI_JOB_ID="50"
 export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a"
 export CI_COMMIT_SHORT_SHA="1ecfd275"
-export CI_COMMIT_REF_NAME="master"
+export CI_COMMIT_REF_NAME="main"
 export CI_REPOSITORY_URL="https://gitlab-ci-token:[masked]@example.com/gitlab-org/gitlab-foss.git"
 export CI_COMMIT_TAG="1.0.0"
 export CI_JOB_NAME="spec:other"
@@ -815,7 +815,7 @@ as well as from in a variable:
 
 ```yaml
 variables:
-  MYSTRING: 'master'
+  MYSTRING: 'main'
   MYREGEX: '/^mast.*/'
 
 testdirect:
@@ -943,8 +943,8 @@ if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then
 ++ CI_PROJECT_VISIBILITY=public
 ++ export CI_PROJECT_REPOSITORY_LANGUAGES=
 ++ CI_PROJECT_REPOSITORY_LANGUAGES=
-++ export CI_DEFAULT_BRANCH=master
-++ CI_DEFAULT_BRANCH=master
+++ export CI_DEFAULT_BRANCH=main
+++ CI_DEFAULT_BRANCH=main
 ++ export CI_REGISTRY=registry.gitlab.com
 ++ CI_REGISTRY=registry.gitlab.com
 ++ export CI_API_V4_URL=https://gitlab.com/api/v4
@@ -961,10 +961,10 @@ if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then
 ++ CI_COMMIT_SHORT_SHA=dd648b2e
 ++ export CI_COMMIT_BEFORE_SHA=0000000000000000000000000000000000000000
 ++ CI_COMMIT_BEFORE_SHA=0000000000000000000000000000000000000000
-++ export CI_COMMIT_REF_NAME=master
-++ CI_COMMIT_REF_NAME=master
-++ export CI_COMMIT_REF_SLUG=master
-++ CI_COMMIT_REF_SLUG=master
+++ export CI_COMMIT_REF_NAME=main
+++ CI_COMMIT_REF_NAME=main
+++ export CI_COMMIT_REF_SLUG=main
+++ CI_COMMIT_REF_SLUG=main
 ...
 ```
 
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 2e00e3c52c6..92b414e0eab 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -1029,7 +1029,7 @@ levels. For example:
     URL: "http://my-url.internal"
     IMPORTANT_VAR: "the details"
   only:
-    - master
+    - main
     - stable
   tags:
     - production
@@ -1062,7 +1062,7 @@ rspec:
     IMPORTANT_VAR: "the details"
     GITLAB: "is-awesome"
   only:
-    - master
+    - main
     - stable
   tags:
     - docker
@@ -2390,7 +2390,7 @@ For example:
 ```yaml
 deploy to production:
   stage: deploy
-  script: git push production HEAD:master
+  script: git push production HEAD:main
   environment: production
 ```
 
@@ -2412,7 +2412,7 @@ Set a name for an [environment](../environments/index.md). For example:
 ```yaml
 deploy to production:
   stage: deploy
-  script: git push production HEAD:master
+  script: git push production HEAD:main
   environment:
     name: production
 ```
@@ -2447,7 +2447,7 @@ Set a URL for an [environment](../environments/index.md). For example:
 ```yaml
 deploy to production:
   stage: deploy
-  script: git push production HEAD:master
+  script: git push production HEAD:main
   environment:
     name: production
     url: https://prod.example.com
diff --git a/doc/ci/yaml/includes.md b/doc/ci/yaml/includes.md
index ce4586f9698..e18d7345d97 100644
--- a/doc/ci/yaml/includes.md
+++ b/doc/ci/yaml/includes.md
@@ -26,7 +26,7 @@ Array with `include` method implied:
 
 ```yaml
 include:
-  - 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
+  - 'https://gitlab.com/awesome-project/raw/main/.before-script-template.yml'
   - '/templates/.after-script-template.yml'
 ```
 
@@ -34,21 +34,21 @@ Single string with `include` method specified explicitly:
 
 ```yaml
 include:
-  remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
+  remote: 'https://gitlab.com/awesome-project/raw/main/.before-script-template.yml'
 ```
 
 Array with `include:remote` being the single item:
 
 ```yaml
 include:
-  - remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
+  - remote: 'https://gitlab.com/awesome-project/raw/main/.before-script-template.yml'
 ```
 
 Array with multiple `include` methods specified explicitly:
 
 ```yaml
 include:
-  - remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
+  - remote: 'https://gitlab.com/awesome-project/raw/main/.before-script-template.yml'
   - local: '/templates/.after-script-template.yml'
   - template: Auto-DevOps.gitlab-ci.yml
 ```
@@ -57,11 +57,11 @@ Array mixed syntax:
 
 ```yaml
 include:
-  - 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
+  - 'https://gitlab.com/awesome-project/raw/main/.before-script-template.yml'
   - '/templates/.after-script-template.yml'
   - template: Auto-DevOps.gitlab-ci.yml
   - project: 'my-group/my-project'
-    ref: master
+    ref: main
     file: '/templates/.gitlab-ci-template.yml'
 ```
 
@@ -70,7 +70,7 @@ include:
 In the following example, the content of `.before-script-template.yml` is
 automatically fetched and evaluated along with the content of `.gitlab-ci.yml`.
 
-Content of `https://gitlab.com/awesome-project/raw/master/.before-script-template.yml`:
+Content of `https://gitlab.com/awesome-project/raw/main/.before-script-template.yml`:
 
 ```yaml
 default:
@@ -83,7 +83,7 @@ default:
 Content of `.gitlab-ci.yml`:
 
 ```yaml
-include: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
+include: 'https://gitlab.com/awesome-project/raw/main/.before-script-template.yml'
 
 rspec:
   script:
@@ -112,7 +112,7 @@ production:
     name: production
     url: https://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
   only:
-    - master
+    - main
 ```
 
 Content of `.gitlab-ci.yml`:
diff --git a/doc/development/usage_ping/dictionary.md b/doc/development/usage_ping/dictionary.md
index 87940469c4d..f4a94d74f7d 100644
--- a/doc/development/usage_ping/dictionary.md
+++ b/doc/development/usage_ping/dictionary.md
@@ -16778,15 +16778,15 @@ Tiers: `free`
 
 ### `usage_activity_by_stage.manage.value_stream_management_customized_group_stages`
 
-Missing description
+Number of custom value stream analytics stages.
 
 [YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210216180803_value_stream_management_customized_group_stages.yml)
 
-Group: `group::manage`
+Group: `group::optimize`
 
 Status: `data_available`
 
-Tiers:
+Tiers: `premium`, `ultimate`
 
 ### `usage_activity_by_stage.monitor.clusters`
 
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index 5a2f1d9f80d..b980e6c1c3c 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -15,7 +15,7 @@ documentation for all current settings and limits on the GitLab.com instance.
 
 ## General
 
-Access the default page for admin area settings by navigating to **Admin Area > Settings > General**:
+Access the default page for Admin Area settings by navigating to **Admin Area > Settings > General**:
 
 | Option | Description |
 | ------ | ----------- |
@@ -27,7 +27,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | [Terms of Service and Privacy Policy](terms.md) | Include a Terms of Service agreement and Privacy Policy that all users must accept. |
 | [External Authentication](external_authorization.md#configuration) | External Classification Policy Authorization |
 | [Web terminal](../../../administration/integration/terminal.md#limiting-websocket-connection-time) | Set max session time for web terminal. |
-| [Web IDE](../../project/web_ide/index.md#enabling-live-preview) | Manage Web IDE Features. |
+| [Web IDE](../../project/web_ide/index.md#enable-live-preview) | Manage Web IDE features. |
 | [FLoC](floc.md) | Enable or disable [Federated Learning of Cohorts (FLoC)](https://en.wikipedia.org/wiki/Federated_Learning_of_Cohorts) tracking. |
 
 ## Integrations
diff --git a/doc/user/project/merge_requests/cherry_pick_changes.md b/doc/user/project/merge_requests/cherry_pick_changes.md
index eaeef12444e..b71c7386301 100644
--- a/doc/user/project/merge_requests/cherry_pick_changes.md
+++ b/doc/user/project/merge_requests/cherry_pick_changes.md
@@ -100,6 +100,11 @@ To disable it:
 Feature.disable(:pick_into_project)
 ```
 
+## Related links
+
+- The [Commits API](../../../api/commits.md) enables you to add custom messages
+  to changes you cherry-pick through the API.
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md
index 73aed1244db..f50a5608ddb 100644
--- a/doc/user/project/web_ide/index.md
+++ b/doc/user/project/web_ide/index.md
@@ -259,19 +259,27 @@ Additionally, for public projects an **Open in CodeSandbox** button is available
 to transfer the contents of the project into a public CodeSandbox project to
 quickly share your project with others.
 
-### Enabling Live Preview
+### Enable Live Preview
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/268288) in GitLab 12.9, third-party assets and libraries required for Live Preview are hosted at `https://sandbox-prod.gitlab-static.net` when it is enabled. However, some libraries are still served from other third-party services which may or may not be desirable in your environment.
+With Live Preview enabled, you can preview projects with a `package.json` file and
+a `main` entry point inside the Web IDE.
 
-The Live Preview feature needs to be enabled in the GitLab instance's
-Admin Area. Live Preview is enabled for all projects on
-GitLab.com
+Live Preview is enabled for all projects on GitLab.com. If you are an administrator
+of a self-managed GitLab instance, and you want to enable Live Preview:
 
-![Administrator Live Preview setting](img/admin_live_preview_v13_0.png)
+1. In the top navigation bar, go to **Admin Area**.
+1. In the left sidebar, select **Settings > General**.
+1. Scroll to **Web IDE** and select **Expand**:
+   ![Administrator Live Preview setting](img/admin_live_preview_v13_0.png)
+1. Select **Enable Live Preview** and select **Save changes**.
 
-After you have done that, you can preview projects with a `package.json` file and
-a `main` entry point inside the Web IDE. An example `package.json` is shown
-below.
+[In GitLab 12.9 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/268288),
+third-party assets and libraries required for Live Preview are hosted at
+`https://sandbox-prod.gitlab-static.net` when it is enabled. However, some libraries
+are still served from other third-party services, which may or may not be desirable
+in your environment.
+
+An example `package.json`:
 
 ```json
 {