Add latest changes from gitlab-org/gitlab@master

8 files changed, 58 insertions, 80 deletions

diff --git a/doc/api/container_registry.md b/doc/api/container_registry.md
index 8fc7c4dc4fe..b61ec34b882 100644
--- a/doc/api/container_registry.md
+++ b/doc/api/container_registry.md
@@ -441,7 +441,7 @@ These are different from project or personal access tokens in the GitLab applica
 ### Listing all container repositories
 
 ```plaintext
-GET /v2/_catalogue
+GET /v2/_catalog
 ```
 
 To list all container repositories on your GitLab instance, admin credentials are required:
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 6d3115e29af..11509e9f8a4 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -5168,7 +5168,7 @@ Input type: `VulnerabilityRevertToDetectedInput`
 
 ### `Mutation.workItemCreate`
 
-Available only when feature flag `work_items` is enabled. This flag is disabled by default, because the feature is experimental and is subject to change without notice.
+Creates a work item. Available only when feature flag `work_items` is enabled. The feature is experimental and is subject to change without notice.
 
 Input type: `WorkItemCreateInput`
 
diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md
index f09f5ff0d60..4976f7c2664 100644
--- a/doc/integration/elasticsearch.md
+++ b/doc/integration/elasticsearch.md
@@ -473,7 +473,7 @@ The following are some available Rake tasks:
 | [`sudo gitlab-rake gitlab:elastic:index`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake)                            | Enables Elasticsearch indexing and run `gitlab:elastic:create_empty_index`, `gitlab:elastic:clear_index_status`, `gitlab:elastic:index_projects`, and `gitlab:elastic:index_snippets`.                          |
 | [`sudo gitlab-rake gitlab:elastic:pause_indexing`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake)                            | Pauses Elasticsearch indexing. Changes are still tracked. Useful for cluster/index migrations. |
 | [`sudo gitlab-rake gitlab:elastic:resume_indexing`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake)                            | Resumes Elasticsearch indexing. |
-| [`sudo gitlab-rake gitlab:elastic:index_projects`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake)                   | Iterates over all projects and queues Sidekiq jobs to index them in the background.                                                                                                       |
+| [`sudo gitlab-rake gitlab:elastic:index_projects`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake)                   | Iterates over all projects, and queues Sidekiq jobs to index them in the background. It can only be used after the index is created.                                                                                                      |
 | [`sudo gitlab-rake gitlab:elastic:index_projects_status`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake)            | Determines the overall status of the indexing. It is done by counting the total number of indexed projects, dividing by a count of the total number of projects, then multiplying by 100. |
 | [`sudo gitlab-rake gitlab:elastic:clear_index_status`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake)               | Deletes all instances of IndexStatus for all projects. Note that this command results in a complete wipe of the index, and it should be used with caution.                                                                                              |
 | [`sudo gitlab-rake gitlab:elastic:create_empty_index`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Generates empty indexes (the default index and a separate issues index) and assigns an alias for each on the Elasticsearch side only if it doesn't already exist.                                                                                                      |
diff --git a/doc/user/clusters/migrating_from_gma_to_project_template.md b/doc/user/clusters/migrating_from_gma_to_project_template.md
index 94e9d4af36a..b2ba1bef338 100644
--- a/doc/user/clusters/migrating_from_gma_to_project_template.md
+++ b/doc/user/clusters/migrating_from_gma_to_project_template.md
@@ -23,16 +23,16 @@ See also [video walk-throughs](#video-walk-throughs) with examples.
 1. Create a new project based on the [Cluster Management Project template](management_project_template.md#create-a-new-project-based-on-the-cluster-management-template).
 1. [Associate your new Cluster Management Project with your cluster](management_project.md#associate-the-cluster-management-project-with-the-cluster).
 1. Detect apps deployed through Helm v2 releases by using the pre-configured [`.gitlab-ci.yml`](management_project_template.md#the-gitlab-ciyml-file) file:
-    - In case you had overwritten the default GitLab Managed Apps namespace, edit `.gitlab-ci.yml`,
-      and make sure the script is receiving the correct namespace as an argument:
+   - In case you had overwritten the default GitLab Managed Apps namespace, edit `.gitlab-ci.yml`,
+     and make sure the script is receiving the correct namespace as an argument:
 
-      ```yaml
-      script:
-        - gl-fail-if-helm2-releases-exist <your_custom_namespace>
-      ```
+     ```yaml
+     script:
+       - gl-fail-if-helm2-releases-exist <your_custom_namespace>
+     ```
 
-    - If you kept the default name (`gitlab-managed-apps`), then the script is already
-      set up.
+   - If you kept the default name (`gitlab-managed-apps`), then the script is already
+     set up.
 
    Either way, [run a pipeline manually](../../ci/pipelines/index.md#run-a-pipeline-manually) and read the logs of the
    `detect-helm2-releases` job to know if you have any Helm v2 releases and which are they.
@@ -53,7 +53,7 @@ See also [video walk-throughs](#video-walk-throughs) with examples.
 
    ```shell
    helm ls -n gitlab-managed-apps
-   
+
    NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
    runner gitlab-managed-apps 1 2021-06-09 19:36:55.739141644 +0000 UTC deployed gitlab-runner-0.28.0 13.11.0
    ```
@@ -67,42 +67,42 @@ See also [video walk-throughs](#video-walk-throughs) with examples.
 1. Edit the `applications/{app}/values.yaml` associated with your app to match the currently
    deployed values. For example, for GitLab Runner:
 
-    1. Copy the output of the following command (it might be big):
+   1. Copy the output of the following command (it might be big):
 
-        ```shell
-        helm get values runner -n gitlab-managed-apps -a --output yaml
-        ```
+      ```shell
+      helm get values runner -n gitlab-managed-apps -a --output yaml
+      ```
 
-    1. Overwrite `applications/gitlab-runner/values.yaml` with the output of the previous command.
+   1. Overwrite `applications/gitlab-runner/values.yaml` with the output of the previous command.
 
    This safe step will guarantee that no unexpected default values overwrite your currently deployed values.
    For instance, your GitLab Runner could have its `gitlabUrl` or `runnerRegistrationToken` overwritten by mistake.
 
 1. Some apps require special attention:
 
-    - Ingress: Due to an existing [chart issue](https://github.com/helm/charts/pull/13646), you might see
-      `spec.clusterIP: Invalid value` when trying to run the [`./gl-helmfile`](management_project_template.md#the-gitlab-ciyml-file)
-      command. To work around this, after overwriting the release values in `applications/ingress/values.yaml`,
-      you might need to overwrite all the occurrences of `omitClusterIP: false`, setting it to `omitClusterIP: true`.
-      Another approach,could be to collect these IPs by running `kubectl get services -n gitlab-managed-apps`
-      and then overwriting each `ClusterIP` that it complains about with the value you got from that command.
-
-    - Vault: This application introduces a breaking change from the chart we used in Helm v2 to the chart
-      used in Helm v3. So, the only way to integrate it with this Cluster Management Project is to actually uninstall this app and accept the
-      chart version proposed in `applications/vault/values.yaml`.
-
-    - Cert-manager:
-      - For users on Kubernetes version 1.20 or above, the deprecated cert-manager v0.10 is no longer valid
-        and the upgrade includes a breaking change. So we suggest that you [backup and uninstall cert-manager v0.10](#backup-and-uninstall-cert-manager-v010),
-        and install the latest cert-manager instead. To install this version, uncomment `applications/cert-manager/helmfile.yaml`
-        from [`./helmfile.yaml`](management_project_template.md#the-main-helmfileyml-file).
-        This triggers a pipeline to install the new version.
-      - For users on Kubernetes versions lower than 1.20, you can stick to v0.10 by uncommenting
-        `applications/cert-manager-legacy/helmfile.yaml`
-        in your project's main Helmfile ([`./helmfile.yaml`](management_project_template.md#the-main-helmfileyml-file)).
-
-        WARNING:
-        Cert-manager v0.10 breaks when Kubernetes is upgraded to version 1.20 or later.
+   - Ingress: Due to an existing [chart issue](https://github.com/helm/charts/pull/13646), you might see
+     `spec.clusterIP: Invalid value` when trying to run the [`./gl-helmfile`](management_project_template.md#the-gitlab-ciyml-file)
+     command. To work around this, after overwriting the release values in `applications/ingress/values.yaml`,
+     you might need to overwrite all the occurrences of `omitClusterIP: false`, setting it to `omitClusterIP: true`.
+     Another approach,could be to collect these IPs by running `kubectl get services -n gitlab-managed-apps`
+     and then overwriting each `ClusterIP` that it complains about with the value you got from that command.
+
+   - Vault: This application introduces a breaking change from the chart we used in Helm v2 to the chart
+     used in Helm v3. So, the only way to integrate it with this Cluster Management Project is to actually uninstall this app and accept the
+     chart version proposed in `applications/vault/values.yaml`.
+
+   - Cert-manager:
+     - For users on Kubernetes version 1.20 or above, the deprecated cert-manager v0.10 is no longer valid
+       and the upgrade includes a breaking change. So we suggest that you [backup and uninstall cert-manager v0.10](#backup-and-uninstall-cert-manager-v010),
+       and install the latest cert-manager instead. To install this version, uncomment `applications/cert-manager/helmfile.yaml`
+       from [`./helmfile.yaml`](management_project_template.md#the-main-helmfileyml-file).
+       This triggers a pipeline to install the new version.
+     - For users on Kubernetes versions lower than 1.20, you can stick to v0.10 by uncommenting
+       `applications/cert-manager-legacy/helmfile.yaml`
+       in your project's main Helmfile ([`./helmfile.yaml`](management_project_template.md#the-main-helmfileyml-file)).
+
+       WARNING:
+       Cert-manager v0.10 breaks when Kubernetes is upgraded to version 1.20 or later.
 
 1. After following all the previous steps, [run a pipeline manually](../../ci/pipelines/index.md#run-a-pipeline-manually)
    and watch the `apply` job logs to see if any of your applications were successfully detected, installed, and whether they got any
@@ -121,7 +121,7 @@ you want to manage with the Cluster Management Project.
 ## Backup and uninstall cert-manager v0.10
 
 1. Follow the [official docs](https://docs.cert-manager.io/en/release-0.10/tasks/backup-restore-crds.html) on how to
-  backup your cert-manager v0.10 data.
+   backup your cert-manager v0.10 data.
 1. Uninstall cert-manager by editing the setting all the occurrences of `installed: true` to `installed: false` in the
    `applications/cert-manager/helmfile.yaml` file.
 1. Search for any left-over resources by executing the following command `kubectl get Issuers,ClusterIssuers,Certificates,CertificateRequests,Orders,Challenges,Secrets,ConfigMaps -n gitlab-managed-apps | grep certmanager`.
diff --git a/doc/user/group/roadmap/index.md b/doc/user/group/roadmap/index.md
index 641fc8a1509..f10dc3bc22a 100644
--- a/doc/user/group/roadmap/index.md
+++ b/doc/user/group/roadmap/index.md
@@ -85,8 +85,10 @@ When you enable the roadmap settings sidebar, you can use it to refine epics sho
 You can configure the following:
 
 - Select date range.
+- Turn milestones on or off and select whether to show all, group, sub-group, or project milestones.
 - Show all, open, or closed epics.
-- Turn progress tracking on or off and select whether it uses issue weights or counts.
+- Turn progress tracking for child issues on or off and select whether
+  to use issue weights or counts.
 
   The progress tracking setting is not saved in user preferences but is saved or shared using URL parameters.
 
diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md
index 4663cfc8bfd..ccf77f79fd9 100644
--- a/doc/user/group/value_stream_analytics/index.md
+++ b/doc/user/group/value_stream_analytics/index.md
@@ -117,16 +117,15 @@ production environment for all merge requests deployed in the given time period.
 The "Recent Activity" metrics near the top of the page are measured as follows:
 
 - **New Issues:** the number of issues created in the date range.
-- **Deploys:** the number of deployments <sup>1</sup> to production <sup>2</sup> in the date range.
-- **Deployment Frequency:** the average number of deployments <sup>1</sup> to production <sup>2</sup>
+- **Deploys:** the number of deployments to production in the date range.
+- **Deployment Frequency:** the average number of deployments to production
    per day in the date range.
 
-1. To give a more accurate representation of deployments that actually completed successfully,
-   the calculation for these two metrics changed in GitLab 13.9 from using the time a deployment was
-   created to the time a deployment finished. If you were referencing this metric prior to 13.9, please
-   keep this slight change in mind.
-1. To see deployment metrics, you must have a
-   [production environment configured](../../../ci/environments/index.md#deployment-tier-of-environments).
+To see deployment metrics, you must have a [production environment configured](../../../ci/environments/index.md#deployment-tier-of-environments).
+
+NOTE:
+In GitLab 13.9 and later, deployment metrics are calculated based on when the deployment was finished.
+In GitLab 13.8 and earlier, deployment metrics are calculated based on when the deployment was created.
 
 You can learn more about these metrics in our [analytics definitions](../../analytics/index.md).
 
diff --git a/doc/user/project/import/bitbucket.md b/doc/user/project/import/bitbucket.md
index 0c50fc77e33..62495872659 100644
--- a/doc/user/project/import/bitbucket.md
+++ b/doc/user/project/import/bitbucket.md
@@ -42,7 +42,7 @@ When issues/pull requests are being imported, the Bitbucket importer tries to fi
 the Bitbucket author/assignee in the GitLab database using the Bitbucket `nickname`.
 For this to work, the Bitbucket author/assignee should have signed in beforehand in GitLab
 and **associated their Bitbucket account**. Their `nickname` must also match their Bitbucket
-`username.`. If the user is not found in the GitLab database, the project creator
+`username`. If the user is not found in the GitLab database, the project creator
 (most of the times the current user that started the import process) is set as the author,
 but a reference on the issue about the original Bitbucket author is kept.
 
diff --git a/doc/user/project/merge_requests/commits.md b/doc/user/project/merge_requests/commits.md
index 8970f958603..0014c1ba994 100644
--- a/doc/user/project/merge_requests/commits.md
+++ b/doc/user/project/merge_requests/commits.md
@@ -29,21 +29,17 @@ To seamlessly navigate among commits in a merge request:
 
 ## View merge request commits in context
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29274) in GitLab 13.12.
-> - [Deployed behind a feature flag](../../feature_flags.md), enabled by default.
-> - Disabled on GitLab.com.
-> - Not recommended for production use.
-> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-viewing-merge-request-commits-in-context).
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29274) in GitLab 13.12 [with a flag](../../../administration/feature_flags.md) named `context_commits`. Enabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/320757) in GitLab 14.8.
 
 WARNING:
 This feature is in [beta](../../../policy/alpha-beta-support.md#beta-features)
 and is [incomplete](https://gitlab.com/groups/gitlab-org/-/epics/1192).
-Previously merged commits can be added, but they can't be removed due to
-[this bug](https://gitlab.com/gitlab-org/gitlab/-/issues/325538).
 
-This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
-Refer to this feature's version history for more details.
+FLAG:
+On self-managed GitLab, by default this feature is available. To hide the feature,
+ask an administrator to [disable the feature flag](../../../administration/feature_flags.md) named `context_commits`.
+On GitLab.com, this feature is available.
 
 When reviewing a merge request, it helps to have more context about the changes
 made. That includes unchanged lines in unchanged files, and previous commits
@@ -66,22 +62,3 @@ To view the changes done on those previously merged commits:
 1. Scroll to **(file-tree)** **Compare** and select **previously merged commits**:
 
    ![Previously merged commits](img/previously_merged_commits_v14_1.png)
-
-### Enable or disable viewing merge request commits in context **(FREE SELF)**
-
-Viewing merge request commits in context is under development and not ready for production use. It is
-deployed behind a feature flag that is **disabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
-can enable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:context_commits)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:context_commits)
-```