Add latest changes from gitlab-org/gitlab@master

10 files changed, 486 insertions, 284 deletions

diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 14ae0c3e8c6..f0d4d216d8e 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -526,7 +526,7 @@ on how to achieve that.
 
 NOTE: **Note:**
 In using an external container registry, some features associated with the
-container registry may be unavailable or have [inherant risks](./../../user/packages/container_registry/index.md#use-with-external-container-registries)
+container registry may be unavailable or have [inherent risks](./../../user/packages/container_registry/index.md#use-with-external-container-registries)
 
 **Omnibus GitLab**
 
diff --git a/doc/administration/raketasks/storage.md b/doc/administration/raketasks/storage.md
index 44592260882..30f50c24138 100644
--- a/doc/administration/raketasks/storage.md
+++ b/doc/administration/raketasks/storage.md
@@ -1,221 +1,162 @@
 # Repository storage Rake tasks **(CORE ONLY)**
 
-This is a collection of Rake tasks you can use to help you list and migrate
-existing projects and attachments associated with it from Legacy storage to
-the new Hashed storage type.
+This is a collection of Rake tasks to help you list and migrate
+existing projects and their attachments to the new
+[hashed storage](../repository_storage_types.md) that GitLab
+uses to organize the Git data.
 
-You can read more about the storage types [here](../repository_storage_types.md).
+## List projects and attachments
 
-## Migrate existing projects to hashed storage
+The following Rake tasks will list the projects and attachments that are
+available on legacy and hashed storage.
 
-Before migrating your existing projects, you should
-[enable hashed storage](../repository_storage_types.md#how-to-migrate-to-hashed-storage) for the new projects as well.
+### On legacy storage
 
-This task will schedule all your existing projects and attachments associated with it to be migrated to the
-**Hashed** storage type:
+To have a summary and then a list of projects and their attachments using legacy storage:
 
-**Omnibus Installation**
+- **Omnibus installation**
 
-```shell
-sudo gitlab-rake gitlab:storage:migrate_to_hashed
-```
+  ```shell
+  # Projects
+  sudo gitlab-rake gitlab:storage:legacy_projects
+  sudo gitlab-rake gitlab:storage:list_legacy_projects
 
-**Source Installation**
+  # Attachments
+  sudo gitlab-rake gitlab:storage:legacy_attachments
+  sudo gitlab-rake gitlab:storage:list_legacy_attachments
+  ```
 
-```shell
-sudo -u git -H bundle exec rake gitlab:storage:migrate_to_hashed RAILS_ENV=production
-```
+- **Source installation**
 
-They both also accept a range as environment variable:
+  ```shell
+  # Projects
+  sudo -u git -H bundle exec rake gitlab:storage:legacy_projects RAILS_ENV=production
+  sudo -u git -H bundle exec rake gitlab:storage:list_legacy_projects RAILS_ENV=production
 
-```shell
-# to migrate any non migrated project from ID 20 to 50.
-export ID_FROM=20
-export ID_TO=50
-```
+  # Attachments
+  sudo -u git -H bundle exec rake gitlab:storage:legacy_attachments RAILS_ENV=production
+  sudo -u git -H bundle exec rake gitlab:storage:list_legacy_attachments RAILS_ENV=production
+  ```
 
-You can monitor the progress in the **{admin}** **Admin Area > Monitoring > Background Jobs** page.
-There is a specific queue you can watch to see how long it will take to finish:
-`hashed_storage:hashed_storage_project_migrate`.
+### On hashed storage
 
-After it reaches zero, you can confirm every project has been migrated by running the commands bellow.
-If you find it necessary, you can run this migration script again to schedule missing projects.
+To have a summary and then a list of projects and their attachments using hashed storage:
 
-Any error or warning will be logged in Sidekiq's log file.
+- **Omnibus installation**
 
-NOTE: **Note:**
-If [Geo](../geo/replication/index.md) is enabled, each project that is successfully migrated
-generates an event to replicate the changes on any **secondary** nodes.
+  ```shell
+  # Projects
+  sudo gitlab-rake gitlab:storage:hashed_projects
+  sudo gitlab-rake gitlab:storage:list_hashed_projects
 
-You only need the `gitlab:storage:migrate_to_hashed` Rake task to migrate your repositories, but we have additional
-commands below that helps you inspect projects and attachments in both legacy and hashed storage.
+  # Attachments
+  sudo gitlab-rake gitlab:storage:hashed_attachments
+  sudo gitlab-rake gitlab:storage:list_hashed_attachments
+  ```
 
-## Rollback from hashed storage to legacy storage
+- **Source installation**
 
-If you need to rollback the storage migration for any reason, you can follow the steps described here.
+  ```shell
+  # Projects
+  sudo -u git -H bundle exec rake gitlab:storage:hashed_projects RAILS_ENV=production
+  sudo -u git -H bundle exec rake gitlab:storage:list_hashed_projects RAILS_ENV=production
 
-NOTE: **Note:**
-Hashed storage will be required in future version of GitLab.
+  # Attachments
+  sudo -u git -H bundle exec rake gitlab:storage:hashed_attachments RAILS_ENV=production
+  sudo -u git -H bundle exec rake gitlab:storage:list_hashed_attachments RAILS_ENV=production
+  ```
 
-To prevent new projects from being created in the Hashed storage,
-you need to undo the [enable hashed storage](../repository_storage_types.md#how-to-migrate-to-hashed-storage) changes.
+## Migrate to hashed storage
 
-This task will schedule all your existing projects and associated attachments to be rolled back to the
-Legacy storage type.
+NOTE: **Note:**
+In GitLab 13.0, [hashed storage](../repository_storage_types.md#hashed-storage)
+is enabled by default and the legacy storage is deprecated.
+Support for legacy storage will be removed in GitLab 14.0. If you're on GitLab
+13.0 and later, switching new projects to legacy storage is not possible.
+The option to choose between hashed and legacy storage in the admin area has
+been disabled.
 
-For Omnibus installations, run the following:
+This task will schedule all your existing projects and attachments associated
+with it to be migrated to the **Hashed** storage type:
 
-```shell
-sudo gitlab-rake gitlab:storage:rollback_to_legacy
-```
+- **Omnibus installation**
 
-For source installations, run the following:
+  ```shell
+  sudo gitlab-rake gitlab:storage:migrate_to_hashed
+  ```
 
-```shell
-sudo -u git -H bundle exec rake gitlab:storage:rollback_to_legacy RAILS_ENV=production
-```
+- **Source installation**
 
-Both commands accept a range as environment variable:
+  ```shell
+  sudo -u git -H bundle exec rake gitlab:storage:migrate_to_hashed RAILS_ENV=production
+  ```
+
+If you have any existing integration, you may want to do a small rollout first,
+to validate. You can do so by specifying an ID range with the operation by using
+the environment variables `ID_FROM` and `ID_TO`. For example, to limit the rollout
+to project IDs 50 to 100 in an Omnibus GitLab installation:
 
 ```shell
-# to rollback any migrated project from ID 20 to 50.
-export ID_FROM=20
-export ID_TO=50
+sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
 ```
 
 You can monitor the progress in the **{admin}** **Admin Area > Monitoring > Background Jobs** page.
-On the **Queues** tab, you can watch the `hashed_storage:hashed_storage_project_rollback` queue to see how long the process will take to finish.
+There is a specific queue you can watch to see how long it will take to finish:
+`hashed_storage:hashed_storage_project_migrate`.
 
-After it reaches zero, you can confirm every project has been rolled back by running the commands bellow.
-If some projects weren't rolled back, you can run this rollback script again to schedule further rollbacks.
+After it reaches zero, you can confirm every project has been migrated by running the commands bellow.
+If you find it necessary, you can run this migration script again to schedule missing projects.
 
 Any error or warning will be logged in Sidekiq's log file.
 
-## List projects
-
-The following are Rake tasks for listing projects.
-
-### List projects on legacy storage
-
-To have a simple summary of projects using legacy storage:
-
-**Omnibus Installation**
-
-```shell
-sudo gitlab-rake gitlab:storage:legacy_projects
-```
-
-**Source Installation**
-
-```shell
-sudo -u git -H bundle exec rake gitlab:storage:legacy_projects RAILS_ENV=production
-```
-
-To list projects using legacy storage:
-
-**Omnibus Installation**
-
-```shell
-sudo gitlab-rake gitlab:storage:list_legacy_projects
-```
-
-**Source Installation**
-
-```shell
-sudo -u git -H bundle exec rake gitlab:storage:list_legacy_projects RAILS_ENV=production
-
-```
-
-### List projects on hashed storage
-
-To have a simple summary of projects using hashed storage:
-
-**Omnibus Installation**
-
-```shell
-sudo gitlab-rake gitlab:storage:hashed_projects
-```
-
-**Source Installation**
-
-```shell
-sudo -u git -H bundle exec rake gitlab:storage:hashed_projects RAILS_ENV=production
-```
-
-To list projects using hashed storage:
-
-**Omnibus Installation**
-
-```shell
-sudo gitlab-rake gitlab:storage:list_hashed_projects
-```
-
-**Source Installation**
-
-```shell
-sudo -u git -H bundle exec rake gitlab:storage:list_hashed_projects RAILS_ENV=production
-```
-
-## List attachments
-
-The following are Rake tasks for listing attachments.
-
-### List attachments on legacy storage
-
-To have a simple summary of project attachments using legacy storage:
-
-**Omnibus Installation**
-
-```shell
-sudo gitlab-rake gitlab:storage:legacy_attachments
-```
-
-**Source Installation**
-
-```shell
-sudo -u git -H bundle exec rake gitlab:storage:legacy_attachments RAILS_ENV=production
-```
+NOTE: **Note:**
+If [Geo](../geo/replication/index.md) is enabled, each project that is successfully migrated
+generates an event to replicate the changes on any **secondary** nodes.
 
-To list project attachments using legacy storage:
+You only need the `gitlab:storage:migrate_to_hashed` Rake task to migrate your repositories, but we have additional
+commands below that helps you inspect projects and attachments in both legacy and hashed storage.
 
-**Omnibus Installation**
+## Rollback from hashed storage to legacy storage
 
-```shell
-sudo gitlab-rake gitlab:storage:list_legacy_attachments
-```
+NOTE: **Deprecated:**
+In GitLab 13.0, [hashed storage](../repository_storage_types.md#hashed-storage)
+is enabled by default and the legacy storage is deprecated.
+Support for legacy storage will be removed in GitLab 14.0. If you're on GitLab
+13.0 and later, switching new projects to legacy storage is not possible.
+The option to choose between hashed and legacy storage in the admin area has
+been disabled.
 
-**Source Installation**
+This task will schedule all your existing projects and associated attachments to be rolled back to the
+legacy storage type.
 
-```shell
-sudo -u git -H bundle exec rake gitlab:storage:list_legacy_attachments RAILS_ENV=production
-```
+- **Omnibus installation**
 
-### List attachments on hashed storage
+  ```shell
+  sudo gitlab-rake gitlab:storage:rollback_to_legacy
+  ```
 
-To have a simple summary of project attachments using hashed storage:
+- **Source installation**
 
-**Omnibus Installation**
+  ```shell
+  sudo -u git -H bundle exec rake gitlab:storage:rollback_to_legacy RAILS_ENV=production
+  ```
 
-```shell
-sudo gitlab-rake gitlab:storage:hashed_attachments
-```
-
-**Source Installation**
+If you have any existing integration, you may want to do a small rollback first,
+to validate. You can do so by specifying an ID range with the operation by using
+the environment variables `ID_FROM` and `ID_TO`. For example, to limit the rollout
+to project IDs 50 to 100 in an Omnibus GitLab installation:
 
 ```shell
-sudo -u git -H bundle exec rake gitlab:storage:hashed_attachments RAILS_ENV=production
+sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100
 ```
 
-To list project attachments using hashed storage:
-
-**Omnibus Installation**
-
-```shell
-sudo gitlab-rake gitlab:storage:list_hashed_attachments
-```
+You can monitor the progress in the **{admin}** **Admin Area > Monitoring > Background Jobs** page.
+On the **Queues** tab, you can watch the `hashed_storage:hashed_storage_project_rollback` queue to see how long the process will take to finish.
 
-**Source Installation**
+After it reaches zero, you can confirm every project has been rolled back by running the commands bellow.
+If some projects weren't rolled back, you can run this rollback script again to schedule further rollbacks.
+Any error or warning will be logged in Sidekiq's log file.
 
-```shell
-sudo -u git -H bundle exec rake gitlab:storage:list_hashed_attachments RAILS_ENV=production
-```
+If you have a Geo setup, the rollback will not be reflected automatically
+on the **secondary** node. You may need to wait for a backfill operation to kick-in and remove
+the remaining repositories from the special `@hashed/` folder manually.
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index e285e938bfc..a95178c01e2 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -1,9 +1,8 @@
-# Repository Storage Types
+# Repository storage types **(CORE ONLY)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/28283) in GitLab 10.0.
-
-Two different storage layouts can be used
-to store the repositories on disk and their characteristics.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/28283) in GitLab 10.0.
+> - Hashed storage became the default for new installations in GitLab 12.0
+> - Hashed storage is enabled by default for new and renamed projects in GitLab 13.0.
 
 GitLab can be configured to use one or multiple repository storage paths/shard
 locations that can be:
@@ -20,40 +19,17 @@ The `default` repository shard that is available in any installations
 that haven't customized it, points to the local folder: `/var/opt/gitlab/git-data`.
 Anything discussed below is expected to be part of that folder.
 
-## Legacy Storage
-
-Legacy Storage is the storage behavior prior to version 10.0. For historical
-reasons, GitLab replicated the same mapping structure from the projects URLs:
-
-- Project's repository: `#{namespace}/#{project_name}.git`
-- Project's wiki: `#{namespace}/#{project_name}.wiki.git`
-
-This structure made it simple to migrate from existing solutions to GitLab and
-easy for Administrators to find where the repository is stored.
-
-On the other hand this has some drawbacks:
-
-Storage location will concentrate huge amount of top-level namespaces. The
-impact can be reduced by the introduction of
-[multiple storage paths](repository_storage_paths.md).
-
-Because backups are a snapshot of the same URL mapping, if you try to recover a
-very old backup, you need to verify whether any project has taken the place of
-an old removed or renamed project sharing the same URL. This means that
-`mygroup/myproject` from your backup may not be the same original project that
-is at that same URL today.
-
-Any change in the URL will need to be reflected on disk (when groups / users or
-projects are renamed). This can add a lot of load in big installations,
-especially if using any type of network based filesystem.
-
-## Hashed Storage
+## Hashed storage
 
-CAUTION: **Important:**
-Geo requires Hashed Storage since 12.0. If you haven't migrated yet,
-check the [migration instructions](#how-to-migrate-to-hashed-storage) ASAP.
+NOTE: **Note:**
+In GitLab 13.0, hashed storage is enabled by default and the legacy storage is
+deprecated. Support for legacy storage will be removed in GitLab 14.0.
+If you haven't migrated yet, check the
+[migration instructions](raketasks/storage.md#migrate-to-hashed-storage).
+The option to choose between hashed and legacy storage in the admin area has
+been disabled.
 
-Hashed Storage is the new storage behavior we rolled out with 10.0. Instead
+Hashed storage is the storage behavior we rolled out with 10.0. Instead
 of coupling project URL and the folder structure where the repository will be
 stored on disk, we are coupling a hash, based on the project's ID. This makes
 the folder structure immutable, and therefore eliminates any requirement to
@@ -134,6 +110,11 @@ The output includes the project ID and the project name:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitaly/issues/1606) in GitLab 12.1.
 
+DANGER: **Danger:**
+Do not run `git prune` or `git gc` in pool repositories! This can
+cause data loss in "real" repositories that depend on the pool in
+question.
+
 Forks of public projects are deduplicated by creating a third repository, the
 object pool, containing the objects from the source project. Using
 `objects/info/alternates`, the source project and forks use the object pool for
@@ -145,71 +126,15 @@ when housekeeping is run on the source project.
 "@pools/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git"
 ```
 
-DANGER: **Danger:**
-Do not run `git prune` or `git gc` in pool repositories! This can
-cause data loss in "real" repositories that depend on the pool in
-question.
-
-### How to migrate to Hashed Storage
-
-To start a migration, enable Hashed Storage for new projects:
-
-1. Go to **Admin > Settings > Repository** and expand the **Repository Storage** section.
-1. Select the **Use hashed storage paths for newly created and renamed projects** checkbox.
-
-Check if the change breaks any existing integration you may have that
-either runs on the same machine as your repositories are located, or may login to that machine
-to access data (for example, a remote backup solution).
-
-To schedule a complete rollout, see the
-[Rake task documentation for storage migration](raketasks/storage.md#migrate-existing-projects-to-hashed-storage) for instructions.
-
-If you do have any existing integration, you may want to do a small rollout first,
-to validate. You can do so by specifying a range with the operation.
-
-This is an example of how to limit the rollout to Project IDs 50 to 100, running in
-an Omnibus GitLab installation:
+### Hashed storage coverage migration
 
-```shell
-sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
-```
-
-Check the [documentation](raketasks/storage.md#migrate-existing-projects-to-hashed-storage) for additional information and instructions for
-source-based installation.
-
-#### Rollback
-
-Similar to the migration, to disable Hashed Storage for new
-projects:
-
-1. Go to **Admin > Settings > Repository** and expand the **Repository Storage** section.
-1. Uncheck the **Use hashed storage paths for newly created and renamed projects** checkbox.
-
-To schedule a complete rollback, see the
-[Rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions.
-
-The rollback task also supports specifying a range of Project IDs. Here is an example
-of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation:
-
-```shell
-sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100
-```
-
-If you have a Geo setup, please note that the rollback will not be reflected automatically
-on the **secondary** node. You may need to wait for a backfill operation to kick-in and remove
-the remaining repositories from the special `@hashed/` folder manually.
-
-### Hashed Storage coverage
-
-We are incrementally moving every storable object in GitLab to the Hashed
-Storage pattern. You can check the current coverage status below (and also see
-the [issue](https://gitlab.com/gitlab-com/infrastructure/issues/2821)).
-
-Note that things stored in an S3 compatible endpoint will not have the downsides
+Files stored in an S3 compatible endpoint will not have the downsides
 mentioned earlier, if they are not prefixed with `#{namespace}/#{project_name}`,
 which is true for CI Cache and LFS Objects.
 
-| Storable Object | Legacy Storage | Hashed Storage | S3 Compatible | GitLab Version |
+In the table below, you can find the coverage of the migration to the hashed storage.
+
+| Storable Object | Legacy storage | Hashed storage | S3 Compatible | GitLab Version |
 | --------------- | -------------- | -------------- | ------------- | -------------- |
 | Repository      | Yes            | Yes            | -             | 10.0           |
 | Attachments     | Yes            | Yes            | -             | 10.2           |
@@ -222,18 +147,16 @@ which is true for CI Cache and LFS Objects.
 | LFS Objects     | Yes            | Similar        | Yes           | 10.0 / 10.7    |
 | Repository pools| No             | Yes            | -             | 11.6           |
 
-#### Implementation Details
-
-##### Avatars
+#### Avatars
 
 Each file is stored in a folder with its `id` from the database. The filename is always `avatar.png` for user avatars.
 When avatar is replaced, `Upload` model is destroyed and a new one takes place with different `id`.
 
-##### CI Artifacts
+#### CI artifacts
 
 CI Artifacts are S3 compatible since **9.4** (GitLab Premium), and available in GitLab Core since **10.6**.
 
-##### LFS Objects
+#### LFS objects
 
 [LFS Objects in GitLab](../topics/git/lfs/index.md) implement a similar
 storage pattern using 2 chars, 2 level folders, following Git's own implementation:
@@ -246,3 +169,39 @@ storage pattern using 2 chars, 2 level folders, following Git's own implementati
 ```
 
 LFS objects are also [S3 compatible](lfs/index.md#storing-lfs-objects-in-remote-object-storage).
+
+## Legacy storage
+
+NOTE: **Deprecated:**
+In GitLab 13.0, hashed storage is enabled by default and the legacy storage is
+deprecated. If you haven't migrated yet, check the
+[migration instructions](raketasks/storage.md#migrate-to-hashed-storage).
+Support for legacy storage will be removed in GitLab 14.0. If you're on GitLab
+13.0 and later, switching new projects to legacy storage is not possible.
+The option to choose between hashed and legacy storage in the admin area has
+been disabled.
+
+Legacy storage is the storage behavior prior to version 10.0. For historical
+reasons, GitLab replicated the same mapping structure from the projects URLs:
+
+- Project's repository: `#{namespace}/#{project_name}.git`
+- Project's wiki: `#{namespace}/#{project_name}.wiki.git`
+
+This structure made it simple to migrate from existing solutions to GitLab and
+easy for Administrators to find where the repository is stored.
+
+On the other hand this has some drawbacks:
+
+Storage location will concentrate huge amount of top-level namespaces. The
+impact can be reduced by the introduction of
+[multiple storage paths](repository_storage_paths.md).
+
+Because backups are a snapshot of the same URL mapping, if you try to recover a
+very old backup, you need to verify whether any project has taken the place of
+an old removed or renamed project sharing the same URL. This means that
+`mygroup/myproject` from your backup may not be the same original project that
+is at that same URL today.
+
+Any change in the URL will need to be reflected on disk (when groups / users or
+projects are renamed). This can add a lot of load in big installations,
+especially if using any type of network based filesystem.
diff --git a/doc/api/graphql/reference/gitlab_schema.graphql b/doc/api/graphql/reference/gitlab_schema.graphql
index 815f9ec470e..3d2d2b47b7e 100644
--- a/doc/api/graphql/reference/gitlab_schema.graphql
+++ b/doc/api/graphql/reference/gitlab_schema.graphql
@@ -946,6 +946,66 @@ type CreateAlertIssuePayload {
 }
 
 """
+Autogenerated input type of CreateAnnotation
+"""
+input CreateAnnotationInput {
+  """
+  A unique identifier for the client performing the mutation.
+  """
+  clientMutationId: String
+
+  """
+  The global id of the cluster to add an annotation to
+  """
+  clusterId: ID
+
+  """
+  The path to a file defining the dashboard on which the annotation should be added
+  """
+  dashboardPath: String!
+
+  """
+  The description of the annotation
+  """
+  description: String!
+
+  """
+  Timestamp indicating ending moment to which the annotation relates
+  """
+  endingAt: Time
+
+  """
+  The global id of the environment to add an annotation to
+  """
+  environmentId: ID
+
+  """
+  Timestamp indicating starting moment to which the annotation relates
+  """
+  startingAt: Time!
+}
+
+"""
+Autogenerated return type of CreateAnnotation
+"""
+type CreateAnnotationPayload {
+  """
+  The created annotation
+  """
+  annotation: MetricsDashboardAnnotation
+
+  """
+  A unique identifier for the client performing the mutation.
+  """
+  clientMutationId: String
+
+  """
+  Errors encountered during execution of the mutation.
+  """
+  errors: [String!]!
+}
+
+"""
 Autogenerated input type of CreateBranch
 """
 input CreateBranchInput {
@@ -6558,6 +6618,7 @@ type Mutation {
   adminSidekiqQueuesDeleteJobs(input: AdminSidekiqQueuesDeleteJobsInput!): AdminSidekiqQueuesDeleteJobsPayload
   boardListUpdateLimitMetrics(input: BoardListUpdateLimitMetricsInput!): BoardListUpdateLimitMetricsPayload
   createAlertIssue(input: CreateAlertIssueInput!): CreateAlertIssuePayload
+  createAnnotation(input: CreateAnnotationInput!): CreateAnnotationPayload
   createBranch(input: CreateBranchInput!): CreateBranchPayload
   createDiffNote(input: CreateDiffNoteInput!): CreateDiffNotePayload
   createEpic(input: CreateEpicInput!): CreateEpicPayload
diff --git a/doc/api/graphql/reference/gitlab_schema.json b/doc/api/graphql/reference/gitlab_schema.json
index 577e764d6a1..3d7c701dbea 100644
--- a/doc/api/graphql/reference/gitlab_schema.json
+++ b/doc/api/graphql/reference/gitlab_schema.json
@@ -2550,6 +2550,166 @@
         },
         {
           "kind": "INPUT_OBJECT",
+          "name": "CreateAnnotationInput",
+          "description": "Autogenerated input type of CreateAnnotation",
+          "fields": null,
+          "inputFields": [
+            {
+              "name": "environmentId",
+              "description": "The global id of the environment to add an annotation to",
+              "type": {
+                "kind": "SCALAR",
+                "name": "ID",
+                "ofType": null
+              },
+              "defaultValue": null
+            },
+            {
+              "name": "clusterId",
+              "description": "The global id of the cluster to add an annotation to",
+              "type": {
+                "kind": "SCALAR",
+                "name": "ID",
+                "ofType": null
+              },
+              "defaultValue": null
+            },
+            {
+              "name": "startingAt",
+              "description": "Timestamp indicating starting moment to which the annotation relates",
+              "type": {
+                "kind": "NON_NULL",
+                "name": null,
+                "ofType": {
+                  "kind": "SCALAR",
+                  "name": "Time",
+                  "ofType": null
+                }
+              },
+              "defaultValue": null
+            },
+            {
+              "name": "endingAt",
+              "description": "Timestamp indicating ending moment to which the annotation relates",
+              "type": {
+                "kind": "SCALAR",
+                "name": "Time",
+                "ofType": null
+              },
+              "defaultValue": null
+            },
+            {
+              "name": "dashboardPath",
+              "description": "The path to a file defining the dashboard on which the annotation should be added",
+              "type": {
+                "kind": "NON_NULL",
+                "name": null,
+                "ofType": {
+                  "kind": "SCALAR",
+                  "name": "String",
+                  "ofType": null
+                }
+              },
+              "defaultValue": null
+            },
+            {
+              "name": "description",
+              "description": "The description of the annotation",
+              "type": {
+                "kind": "NON_NULL",
+                "name": null,
+                "ofType": {
+                  "kind": "SCALAR",
+                  "name": "String",
+                  "ofType": null
+                }
+              },
+              "defaultValue": null
+            },
+            {
+              "name": "clientMutationId",
+              "description": "A unique identifier for the client performing the mutation.",
+              "type": {
+                "kind": "SCALAR",
+                "name": "String",
+                "ofType": null
+              },
+              "defaultValue": null
+            }
+          ],
+          "interfaces": null,
+          "enumValues": null,
+          "possibleTypes": null
+        },
+        {
+          "kind": "OBJECT",
+          "name": "CreateAnnotationPayload",
+          "description": "Autogenerated return type of CreateAnnotation",
+          "fields": [
+            {
+              "name": "annotation",
+              "description": "The created annotation",
+              "args": [
+
+              ],
+              "type": {
+                "kind": "OBJECT",
+                "name": "MetricsDashboardAnnotation",
+                "ofType": null
+              },
+              "isDeprecated": false,
+              "deprecationReason": null
+            },
+            {
+              "name": "clientMutationId",
+              "description": "A unique identifier for the client performing the mutation.",
+              "args": [
+
+              ],
+              "type": {
+                "kind": "SCALAR",
+                "name": "String",
+                "ofType": null
+              },
+              "isDeprecated": false,
+              "deprecationReason": null
+            },
+            {
+              "name": "errors",
+              "description": "Errors encountered during execution of the mutation.",
+              "args": [
+
+              ],
+              "type": {
+                "kind": "NON_NULL",
+                "name": null,
+                "ofType": {
+                  "kind": "LIST",
+                  "name": null,
+                  "ofType": {
+                    "kind": "NON_NULL",
+                    "name": null,
+                    "ofType": {
+                      "kind": "SCALAR",
+                      "name": "String",
+                      "ofType": null
+                    }
+                  }
+                }
+              },
+              "isDeprecated": false,
+              "deprecationReason": null
+            }
+          ],
+          "inputFields": null,
+          "interfaces": [
+
+          ],
+          "enumValues": null,
+          "possibleTypes": null
+        },
+        {
+          "kind": "INPUT_OBJECT",
           "name": "CreateBranchInput",
           "description": "Autogenerated input type of CreateBranch",
           "fields": null,
@@ -18570,6 +18730,33 @@
               "deprecationReason": null
             },
             {
+              "name": "createAnnotation",
+              "description": null,
+              "args": [
+                {
+                  "name": "input",
+                  "description": null,
+                  "type": {
+                    "kind": "NON_NULL",
+                    "name": null,
+                    "ofType": {
+                      "kind": "INPUT_OBJECT",
+                      "name": "CreateAnnotationInput",
+                      "ofType": null
+                    }
+                  },
+                  "defaultValue": null
+                }
+              ],
+              "type": {
+                "kind": "OBJECT",
+                "name": "CreateAnnotationPayload",
+                "ofType": null
+              },
+              "isDeprecated": false,
+              "deprecationReason": null
+            },
+            {
               "name": "createBranch",
               "description": null,
               "args": [
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index c88e3a3d9da..e2d18ee3f14 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -175,6 +175,16 @@ Autogenerated return type of CreateAlertIssue
 | `errors` | String! => Array | Errors encountered during execution of the mutation. |
 | `issue` | Issue | The issue created after mutation |
 
+## CreateAnnotationPayload
+
+Autogenerated return type of CreateAnnotation
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `annotation` | MetricsDashboardAnnotation | The created annotation |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Errors encountered during execution of the mutation. |
+
 ## CreateBranchPayload
 
 Autogenerated return type of CreateBranch
diff --git a/doc/development/import_export.md b/doc/development/import_export.md
index 40a56679f2f..6d1b6929667 100644
--- a/doc/development/import_export.md
+++ b/doc/development/import_export.md
@@ -339,14 +339,13 @@ Fixtures used in Import/Export specs live in `spec/fixtures/lib/gitlab/import_ex
 There are two versions of each of these fixtures:
 
 - A human readable single JSON file with all objects, called either `project.json` or `group.json`.
-- A tree.tar.gz file containing a tree of files in `ndjson` format. **Please do not edit this file manually unless strictly necessary.**
+- A folder named `tree`, containing a tree of files in `ndjson` format. **Please do not edit files under this folder manually unless strictly necessary.**
 
 The tools to generate the NDJSON tree from the human-readable JSON files live in the [`gitlab-org/memory-team/team-tools`](https://gitlab.com/gitlab-org/memory-team/team-tools/-/blob/master/import-export/) project.
 
 ### Project
 
 **Please use `legacy-project-json-to-ndjson.sh` to generate the NDJSON tree.**
-Once you're done generating the files, please package them using `tar -czf tree.tar.gz tree` from the same directory as the `tree` directory generated is located.
 
 The NDJSON tree will look like this:
 
@@ -380,10 +379,7 @@ tree
 
 ### Group
 
-**Please use `legacy-group-json-to-ndjson.rb` to generate the NDJSON tree.** This script can be found in [`gitlab-org/memory-team/team-tools!7`](https://gitlab.com/gitlab-org/memory-team/team-tools/-/merge_requests/7).
-Once this MR is merged, the script will be found in the directory mentioned earlier.
-
-Once you're done generating the files, please package them using `tar -czf tree.tar.gz tree` from the same directory as the `tree` directory generated is located.
+**Please use `legacy-group-json-to-ndjson.rb` to generate the NDJSON tree.**
 
 The NDJSON tree will look like this:
 
@@ -409,4 +405,4 @@ tree
     └── 4352.json
 ```
 
-CAUTION: **Caution:** When updating these fixtures, please ensure you update the `json` files and the `tar.gz` archives, as the tests apply to both.
+CAUTION: **Caution:** When updating these fixtures, please ensure you update both `json` files and `tree` folder, as the tests apply to both.
diff --git a/doc/development/licensed_feature_availability.md b/doc/development/licensed_feature_availability.md
index 29e4ace157b..4f962b6f5e2 100644
--- a/doc/development/licensed_feature_availability.md
+++ b/doc/development/licensed_feature_availability.md
@@ -35,3 +35,7 @@ the instance license.
 ```ruby
 License.feature_available?(:feature_symbol)
 ```
+
+## Enabling promo features on GitLab.com
+
+A paid feature can be made available to everyone on GitLab.com by enabling the feature flag `"promo_#{feature}"`.
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index bc1afea9bb7..761d640c535 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -44,7 +44,7 @@ Access the default page for admin area settings by navigating to
 | Option | Description |
 | ------ | ----------- |
 | [Repository mirror](visibility_and_access_controls.md#allow-mirrors-to-be-set-up-for-projects) | Configure repository mirroring. |
-| [Repository storage](../../../administration/repository_storage_types.md#how-to-migrate-to-hashed-storage) | Configure storage path settings. |
+| [Repository storage](../../../administration/repository_storage_types.md) | Configure storage path settings. |
 | Repository maintenance | ([Repository checks](../../../administration/repository_checks.md) and [Housekeeping](../../../administration/housekeeping.md)). Configure automatic Git checks and housekeeping on repositories. |
 | [Repository static objects](../../../administration/static_objects_external_storage.md) | Serve repository static objects (for example, archives, blobs, ...) from an external storage (for example, a CDN). |
 
diff --git a/doc/user/packages/container_registry/index.md b/doc/user/packages/container_registry/index.md
index 55dc048222e..f7a6858c3cb 100644
--- a/doc/user/packages/container_registry/index.md
+++ b/doc/user/packages/container_registry/index.md
@@ -492,7 +492,7 @@ older tags and images are regularly removed from the Container Registry.
 NOTE: **Note:**
 Expiration policies for projects created before GitLab 12.8 may be enabled by an
 admin in the [CI/CD Package Registry settings](./../../admin_area/settings/index.md#cicd).
-Note the inherant [risks involved](./index.md#use-with-external-container-registries).
+Note the inherent [risks involved](./index.md#use-with-external-container-registries).
 
 It is possible to create a per-project expiration policy, so that you can make sure that
 older tags and images are regularly removed from the Container Registry.
@@ -542,7 +542,7 @@ See the API documentation for further details: [Edit project](../../../api/proje
 ### Use with external container registries
 
 When using an [external container registry](./../../../administration/packages/container_registry.md#use-an-external-container-registry-with-gitlab-as-an-auth-endpoint),
-running an experation policy on a project may have some performance risks. If a project is going to run
+running an expiration policy on a project may have some performance risks. If a project is going to run
 a policy that will remove large quantities of tags (in the thousands), the GitLab background jobs that
 run the policy may get backed up or fail completely. It is recommended you only enable container expiration
 policies for projects that were created before GitLab 12.8 if you are confident the amount of tags
@@ -577,3 +577,47 @@ Troubleshooting the GitLab Container Registry, most of the times, requires
 administration access to the GitLab server.
 
 [Read how to troubleshoot the Container Registry](../../../administration/packages/container_registry.md#troubleshooting).
+
+### Unable to change path or transfer a project
+
+If you try to change a project's path or transfer a project to a new namespace,
+you may receive one of the following errors:
+
+- "Project cannot be transferred, because tags are present in its container registry."
+- "Namespace cannot be moved because at least one project has tags in container registry."
+
+This issue occurs when the project has images in the Container Registry.
+You must delete or move these images before you can change the path or transfer
+the project.
+
+The following procedure uses these sample project names:
+
+- For the current project: `example.gitlab.com/org/build/sample_project/cr:v2.9.1`
+- For the new project: `example.gitlab.com/new_org/build/new_sample_project/cr:v2.9.1`
+
+Use your own URLs to complete the following steps:
+
+1. Download the Docker images on your computer:
+
+   ```shell
+   docker login example.gitlab.com
+   docker pull example.gitlab.com/org/build/sample_project/cr:v2.9.1
+   ```
+
+1. Rename the images to match the new project name:
+
+   ```shell
+   docker tag example.gitlab.com/org/build/sample_project/cr:v2.9.1 example.gitlab.com/new_org/build/new_sample_project/cr:v2.9.1
+   ```
+
+1. Delete the images in both projects by using the [UI](#delete-images) or [API](../../../api/packages.md#delete-a-project-package).
+   There may be a delay while the images are queued and deleted.
+1. Change the path or transfer the project by going to **Settings > General**
+   and expanding **Advanced**.
+1. Restore the images:
+
+   ```shell
+   docker push example.gitlab.com/new_org/build/new_sample_project/cr:v2.9.1
+   ```
+
+Follow [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/18383) for details.