Add latest changes from gitlab-org/gitlab@master

31 files changed, 284 insertions, 179 deletions

diff --git a/doc/administration/auth/cognito.md b/doc/administration/auth/cognito.md
index b4df6446835..e777acd0d32 100644
--- a/doc/administration/auth/cognito.md
+++ b/doc/administration/auth/cognito.md
@@ -37,7 +37,7 @@ The following steps enable AWS Cognito as an authentication provider:
 
 1. Save changes for the app client settings.
 1. Under **Domain name** include the AWS domain name for your AWS Cognito application.
-1. Under **App Clients**, find your **App client id** and **App client secret**. These values correspond to the OAuth2 Client ID and Client Secret. Save these values.
+1. Under **App Clients**, find your app client ID and app client secret. These values correspond to the OAuth2 Client ID and Client Secret. Save these values.
 
 ## Configure GitLab
 
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 9558488c89e..70e3f0c38c7 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -1072,6 +1072,24 @@ You can run a gRPC trace with:
 sudo GRPC_TRACE=all GRPC_VERBOSITY=DEBUG gitlab-rake gitlab:gitaly:check
 ```
 
+### Correlating Git processes with RPCs
+
+Sometimes you need to find out which Gitaly RPC created a particular Git process.
+
+One method for doing this is via `DEBUG` logging. However, this needs to be enabled
+ahead of time and the logs produced are quite verbose.
+
+A lightweight method for doing this correlation is by inspecting the environment
+of the Git process (using its `PID`) and looking at the `CORRELATION_ID` variable:
+
+```shell
+PID=<Git process ID>
+sudo cat /proc/$PID/environ | tr '\0' '\n' | grep ^CORRELATION_ID=
+```
+
+Please note that this method is not reliable for `git cat-file` processes because Gitaly
+internally pools and re-uses those across RPCs.
+
 ### Observing `gitaly-ruby` traffic
 
 [`gitaly-ruby`](#gitaly-ruby) is an internal implementation detail of Gitaly,
diff --git a/doc/administration/troubleshooting/tracing_correlation_id.md b/doc/administration/troubleshooting/tracing_correlation_id.md
index 31f537beae5..f716e74f36a 100644
--- a/doc/administration/troubleshooting/tracing_correlation_id.md
+++ b/doc/administration/troubleshooting/tracing_correlation_id.md
@@ -38,7 +38,7 @@ value that was randomly generated by GitLab for the request.
 
 See the following example:
 
-![Firefox's network monitor showing an request id header](img/network_monitor_xid.png)
+![Firefox's network monitor showing an request ID header](img/network_monitor_xid.png)
 
 ### Getting the correlation ID from your logs
 
diff --git a/doc/api/feature_flags.md b/doc/api/feature_flags.md
index 479f82914a9..1088154b599 100644
--- a/doc/api/feature_flags.md
+++ b/doc/api/feature_flags.md
@@ -212,11 +212,11 @@ PUT /projects/:id/feature_flags/:feature_flag_name
 | `active`            | boolean          | no         | The active state of the flag. [Supported](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38350) in GitLab 13.3 and later. |
 | `name`              | string           | no         | The new name of the feature flag. [Supported](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38350) in GitLab 13.3 and later. |
 | `strategies`        | JSON             | no         | The feature flag [strategies](../operations/feature_flags.md#feature-flag-strategies). |
-| `strategies:id`     | JSON             | no         | The feature flag strategy id.                                                          |
+| `strategies:id`     | JSON             | no         | The feature flag strategy ID.                                                          |
 | `strategies:name`   | JSON             | no         | The strategy name.                                                                     |
 | `strategies:parameters` | JSON         | no         | The strategy parameters.                                                               |
 | `strategies:scopes` | JSON             | no         | The scopes for the strategy.                                                           |
-| `strategies:scopes:id` | JSON          | no         | The scopes id.                                                                         |
+| `strategies:scopes:id` | JSON          | no         | The scopes ID.                                                                         |
 | `strategies:scopes:environment_scope` | string | no | The environment spec for the scope.                                                    |
 
 ```shell
diff --git a/doc/api/graphql/getting_started.md b/doc/api/graphql/getting_started.md
index 12665f68f25..c2220403461 100644
--- a/doc/api/graphql/getting_started.md
+++ b/doc/api/graphql/getting_started.md
@@ -192,7 +192,7 @@ When you see the result `id` of the note you created - take a note of it. Now le
 
 ```graphql
 mutation {
-  updateNote(input: { id: "gid://gitlab/Note/<note id>",
+  updateNote(input: { id: "gid://gitlab/Note/<note ID>",
       body: "*SIPS TEA*"
     }) {
     note {
@@ -210,7 +210,7 @@ Let's delete the comment, since our tea is all gone.
 
 ```graphql
 mutation {
-  destroyNote(input: { id: "gid://gitlab/Note/<note id>" }) {
+  destroyNote(input: { id: "gid://gitlab/Note/<note ID>" }) {
     note {
       id
       body
diff --git a/doc/api/graphql/reference/gitlab_schema.graphql b/doc/api/graphql/reference/gitlab_schema.graphql
index 1d920894eec..f1bc1f49353 100644
--- a/doc/api/graphql/reference/gitlab_schema.graphql
+++ b/doc/api/graphql/reference/gitlab_schema.graphql
@@ -3131,7 +3131,7 @@ input DeleteAnnotationInput {
   clientMutationId: String
 
   """
-  The global id of the annotation to delete
+  The global ID of the annotation to delete
   """
   id: ID!
 }
@@ -8176,7 +8176,7 @@ type JiraUser {
   gitlabUsername: String
 
   """
-  Account id of the Jira user
+  Account ID of the Jira user
   """
   jiraAccountId: String!
 
diff --git a/doc/api/graphql/reference/gitlab_schema.json b/doc/api/graphql/reference/gitlab_schema.json
index 7ee37fb4d43..91b7eef7816 100644
--- a/doc/api/graphql/reference/gitlab_schema.json
+++ b/doc/api/graphql/reference/gitlab_schema.json
@@ -8464,7 +8464,7 @@
           "inputFields": [
             {
               "name": "id",
-              "description": "The global id of the annotation to delete",
+              "description": "The global ID of the annotation to delete",
               "type": {
                 "kind": "NON_NULL",
                 "name": null,
@@ -22659,7 +22659,7 @@
             },
             {
               "name": "jiraAccountId",
-              "description": "Account id of the Jira user",
+              "description": "Account ID of the Jira user",
               "args": [
 
               ],
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 8ba1862b009..c33ee00a959 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -1254,7 +1254,7 @@ Autogenerated return type of JiraImportUsers
 | `gitlabId` | Int | ID of the matched GitLab user |
 | `gitlabName` | String | Name of the matched GitLab user |
 | `gitlabUsername` | String | Username of the matched GitLab user |
-| `jiraAccountId` | String! | Account id of the Jira user |
+| `jiraAccountId` | String! | Account ID of the Jira user |
 | `jiraDisplayName` | String! | Display name of the Jira user |
 | `jiraEmail` | String | Email of the Jira user, returned only for users with public emails |
 
diff --git a/doc/api/services.md b/doc/api/services.md
index 25ad025027a..405047a433d 100644
--- a/doc/api/services.md
+++ b/doc/api/services.md
@@ -807,7 +807,7 @@ Parameters:
 | `username`      | string | yes  | The username of the user created to be used with GitLab/Jira. |
 | `password`      | string | yes  | The password of the user created to be used with GitLab/Jira. |
 | `active`        | boolean | no  | Activates or deactivates the service. Defaults to false (deactivated). |
-| `jira_issue_transition_id` | string | no | The ID of a transition that moves issues to a closed state. You can find this number under the Jira workflow administration (**Administration > Issues > Workflows**) by selecting **View** under **Operations** of the desired workflow of your project. The ID of each state can be found inside the parenthesis of each transition name under the **Transitions (id)** column. By default, this ID is set to `2`. |
+| `jira_issue_transition_id` | string | no | The ID of a transition that moves issues to a closed state. You can find this number under the Jira workflow administration (**Administration > Issues > Workflows**) by selecting **View** under **Operations** of the desired workflow of your project. The ID of each state can be found inside the parenthesis of each transition name under the transitions ID column. By default, this ID is set to `2`. |
 | `commit_events` | boolean | false | Enable notifications for commit events |
 | `merge_requests_events` | boolean | false | Enable notifications for merge request events |
 | `comment_on_event_enabled` | boolean | false | Enable comments inside Jira issues on each GitLab event (commit / merge request) |
diff --git a/doc/ci/directed_acyclic_graph/index.md b/doc/ci/directed_acyclic_graph/index.md
index 8fc58df51fe..ed1528bf6ca 100644
--- a/doc/ci/directed_acyclic_graph/index.md
+++ b/doc/ci/directed_acyclic_graph/index.md
@@ -106,5 +106,5 @@ can opt to disable it for your instance:
 # Instance-wide
 Feature.disable(:dag_pipeline_tab)
 # or by project
-Feature.disable(:dag_pipeline_tab, Project.find(<project id>))
+Feature.disable(:dag_pipeline_tab, Project.find(<project ID>))
 ```
diff --git a/doc/ci/multi_project_pipelines.md b/doc/ci/multi_project_pipelines.md
index 3df2db8539e..1dee933c126 100644
--- a/doc/ci/multi_project_pipelines.md
+++ b/doc/ci/multi_project_pipelines.md
@@ -272,7 +272,8 @@ You can trigger a pipeline in your project whenever a pipeline finishes for a ne
 tag in a different project:
 
 1. Go to the project's **Settings > CI / CD** page, and expand the **Pipeline subscriptions** section.
-1. Enter the path to the project you want to subscribe to.
+1. Enter the project you want to subscribe to, in the format `<namespace>/<project>`.
+   For example, if the project is `https://gitlab.com/gitlab-org/gitlab`, use `gitlab-org/gitlab`.
 1. Click subscribe.
 
 Any pipelines that complete successfully for new tags in the subscribed project
diff --git a/doc/development/documentation/feature_flags.md b/doc/development/documentation/feature_flags.md
index e2fbf25eb8a..8ad7ef64587 100644
--- a/doc/development/documentation/feature_flags.md
+++ b/doc/development/documentation/feature_flags.md
@@ -75,7 +75,7 @@ To enable it:
 # Instance-wide
 Feature.enable(:<feature flag>)
 # or by project
-Feature.enable(:<feature flag>, Project.find(<project id>))
+Feature.enable(:<feature flag>, Project.find(<project ID>))
 ```
 
 To disable it:
@@ -84,7 +84,7 @@ To disable it:
 # Instance-wide
 Feature.disable(:<feature flag>)
 # or by project
-Feature.disable(:<feature flag>, Project.find(<project id>))
+Feature.disable(:<feature flag>, Project.find(<project ID>))
 ```
 ````
 
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md
index 2f01692e944..614b2579ec3 100644
--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
@@ -229,7 +229,7 @@ be used both locally in development and on any deployed GitLab instance to
 diagnose poor search performance. This will show the exact queries being made,
 which is useful to diagnose why a search might be slow.
 
-### Correlation ID and X-Opaque-Id
+### Correlation ID and `X-Opaque-Id`
 
 Our [correlation
 ID](./distributed_tracing.md#developer-guidelines-for-working-with-correlation-ids)
diff --git a/doc/development/geo/framework.md b/doc/development/geo/framework.md
index 64c9030e3dd..fc8a1c56d67 100644
--- a/doc/development/geo/framework.md
+++ b/doc/development/geo/framework.md
@@ -128,7 +128,7 @@ When this is set in place, it's easy to access the replicator through
 the model:
 
 ```ruby
-package_file = Packages::PackageFile.find(4) # just a random id as example
+package_file = Packages::PackageFile.find(4) # just a random ID as example
 replicator = package_file.replicator
 ```
 
diff --git a/doc/development/telemetry/snowplow.md b/doc/development/telemetry/snowplow.md
index 547ba36464b..f01c2ec95c3 100644
--- a/doc/development/telemetry/snowplow.md
+++ b/doc/development/telemetry/snowplow.md
@@ -393,7 +393,7 @@ Snowplow Micro is a Docker-based solution for testing frontend and backend event
 1. Send a test Snowplow event from the Rails console:
 
    ```ruby
-   Gitlab::Tracking.self_describing_event('iglu:com.gitlab/pageview_context/jsonschema/1-0-0', { page_type: ‘MY_TYPE' }, context: nil )
+   Gitlab::Tracking.self_describing_event('iglu:com.gitlab/pageview_context/jsonschema/1-0-0', { page_type: 'MY_TYPE' }, context: nil )
    ```
 
 ### Snowplow Mini
diff --git a/doc/development/telemetry/usage_ping.md b/doc/development/telemetry/usage_ping.md
index be599898214..383fb4a126b 100644
--- a/doc/development/telemetry/usage_ping.md
+++ b/doc/development/telemetry/usage_ping.md
@@ -222,38 +222,77 @@ Examples of implementation:
 
 #### Redis HLL Counters
 
-With `Gitlab::Redis::HLL` we have available data structures used to count unique values.
+With `Gitlab::UsageDataCounters::HLLRedisCounter` we have available data structures used to count unique values.
 
 Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd) and [PFCOUNT](https://redis.io/commands/pfcount).
 
-Recommendations:
+##### Adding new events
 
-- Key should expire in 29 days.
-- If possible, data granularity should be a week. For example a key could be composed from the metric's name and week of the year, `2020-33-{metric_name}`.
-- Use a [feature flag](../../operations/feature_flags.md) in order to have a control over the impact when adding new metrics.
-- If possible, data granularity should be week, for example a key could be composed from metric name and week of the year, 2020-33-{metric_name}
-- Use a [feature flag](../../operations/feature_flags.md) in order to have a control over the impact when adding new metrics
+1. Define events in [`known_events.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events.yml).
 
-Examples of implementation:
+   Example event:
 
-- [`Gitlab::UsageDataCounters::TrackUniqueEvents`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/track_unique_actions.rb)
-- [`Gitlab::Analytics::UniqueVisits`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/analytics/unique_visits.rb)
+   ```yaml
+   - name: i_compliance_credential_inventory
+     category: compliance
+     redis_slot: compliance
+     expiry: 42 # 6 weeks
+     aggregation: weekly
+   ```
 
-Example of usage:
+   Keys:
+
+   - `name`: unique event name.
+   - `category`: event category. Used for getting total counts for events in a category, for easier
+     access to a group of events.
+   - `redis_slot`: optional Redis slot; default value: event name. Used if needed to calculate totals
+     for a group of metrics. Ensure keys are in the same slot. For example:
+     `i_compliance_credential_inventory` with `redis_slot: 'compliance'` will build Redis key
+     `i_{compliance}_credential_inventory-2020-34`. If `redis_slot` is not defined the Redis key will
+     be `{i_compliance_credential_inventory}-2020-34`.
+   - `expiry`: expiry time in days. Default: 29 days for daily aggregation and 6 weeks for weekly
+     aggregation.
+   - `aggregation`: aggregation `:daily` or `:weekly`. The argument defines how we build the Redis
+     keys for data storage. For `daily` we keep a key for metric per day of the year, for `weekly` we
+     keep a key for metric per week of the year.
+
+1. Track event using `Gitlab::UsageDataCounters::HLLRedisCounter.track_event(entity_id, event_name)`.
+
+   Arguments:
+
+   - `entity_id`: value we count. For example: user_id, visitor_id.
+   - `event_name`: event name.
+
+1. Get event data using `Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names:, start_date:, end_date)`.
+
+   Arguments:
+
+   - `event_names`: the list of event names.
+   - `start_date`: start date of the period for which we want to get event data.
+   - `end_date`: end date of the period for which we want to get event data.
+
+Recommendations:
+
+- Key should expire in 29 days for daily and 42 days for weekly.
+- If possible, data granularity should be a week. For example a key could be composed from the
+  metric's name and week of the year, `2020-33-{metric_name}`.
+- Use a [feature flag](../../operations/feature_flags.md) to have a control over the impact when
+  adding new metrics.
+
+Example usage:
 
 ```ruby
 # Redis Counters
 redis_usage_data(Gitlab::UsageDataCounters::WikiPageCounter)
 redis_usage_data { ::Gitlab::UsageCounters::PodLogs.usage_totals[:total] }
 
-# Redis HLL counter
-counter = Gitlab::UsageDataCounters::TrackUniqueEvents
-redis_usage_data do
-          counter.count_unique_events(
-            event_action: Gitlab::UsageDataCounters::TrackUniqueEvents::PUSH_ACTION,
-            date_from: time_period[:created_at].first,
-            date_to: time_period[:created_at].last
-          )
+# Define events in known_events.yml https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events.yml
+
+# Tracking events
+Gitlab::UsageDataCounters::HLLRedisCounter.track_event(visitor_id, 'expand_vulnerabilities')
+
+# Get unique events for metric
+redis_usage_data { Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'expand_vulnerabilities', start_date: 28.days.ago, end_date: Date.current) }
 ```
 
 ### Alternative Counters
diff --git a/doc/integration/salesforce.md b/doc/integration/salesforce.md
index 64eac2f9e66..7e0b2518e76 100644
--- a/doc/integration/salesforce.md
+++ b/doc/integration/salesforce.md
@@ -21,7 +21,7 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
 1. Select **API (Enable OAuth Settings)** and click on **Enable OAuth Settings**.
 1. Fill in the application details into the following fields:
    - **Callback URL**: The callback URL of your GitLab installation. For example, `https://gitlab.example.com/users/auth/salesforce/callback`.
-   - **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (OpenID)** to the right column.
+   - **Selected OAuth Scopes**: Move `Access your basic information (id, profile, email, address, phone)` and `Allow access to your unique identifier (openid)` to the right column.
 
    ![Salesforce OAuth App Details](img/salesforce_oauth_app_details.png)
 
diff --git a/doc/operations/feature_flags.md b/doc/operations/feature_flags.md
index 46a57e72484..8c79079f595 100644
--- a/doc/operations/feature_flags.md
+++ b/doc/operations/feature_flags.md
@@ -332,8 +332,8 @@ unleash = Unleash::Client.new({
 })
 
 unleash_context = Unleash::Context.new
-# Replace "123" with the id of an authenticated user.
-# Note that the context's user id must be a string:
+# Replace "123" with the ID of an authenticated user.
+# Note that the context's user ID must be a string:
 # https://unleash.github.io/docs/unleash_context
 unleash_context.user_id = "123"
 
diff --git a/doc/operations/incident_management/alerts.md b/doc/operations/incident_management/alerts.md
index 5a5fc59d5e3..04077905af2 100644
--- a/doc/operations/incident_management/alerts.md
+++ b/doc/operations/incident_management/alerts.md
@@ -14,7 +14,7 @@ but you can change the sort order by clicking the headers in the Alert Managemen
 
 The alert list displays the following information:
 
-![Alert List](../../user/project/operations/img/alert_list_v13_1.png)
+![Alert List](img/alert_list_v13_1.png)
 
 - **Search** - The alert list supports a simple free text search on the title,
   description, monitoring tool, and service fields.
@@ -67,11 +67,11 @@ To populate the alerts with data, read
 
 GitLab provides the Generic Alerts endpoint so you can accept alerts from a third-party
 alerts service. Read the
-[instructions for toggling generic alerts](../../user/project/integrations/generic_alerts.md#setting-up-generic-alerts)
+[instructions for toggling generic alerts](generic_alerts.md#setting-up-generic-alerts)
 to add this option. After configuring the endpoint, the
 [Alerts list](alerts.md) is enabled.
 
-To populate the alerts with data, read [Customizing the payload](../../user/project/integrations/generic_alerts.md#customizing-the-payload) for requests to the alerts endpoint.
+To populate the alerts with data, read [Customizing the payload](generic_alerts.md#customizing-the-payload) for requests to the alerts endpoint.
 
 ### Opsgenie integration **(PREMIUM)**
 
@@ -82,7 +82,7 @@ A new way of monitoring Alerts via a GitLab integration is with
 
 NOTE: **Note:**
 If you enable the Opsgenie integration, you can't have other GitLab alert services,
-such as [Generic Alerts](../../user/project/integrations/generic_alerts.md) or
+such as [Generic Alerts](generic_alerts.md) or
 Prometheus alerts, active at the same time.
 
 To enable Opsgenie integration:
diff --git a/doc/operations/incident_management/generic_alerts.md b/doc/operations/incident_management/generic_alerts.md
new file mode 100644
index 00000000000..56a2715ab04
--- /dev/null
+++ b/doc/operations/incident_management/generic_alerts.md
@@ -0,0 +1,125 @@
+---
+stage: Monitor
+group: Health
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Generic alerts integration
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13203) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.4.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/42640) to [GitLab Core](https://about.gitlab.com/pricing/) in 12.8.
+
+GitLab can accept alerts from any source via a generic webhook receiver.
+When you set up the generic alerts integration, a unique endpoint will
+be created which can receive a payload in JSON format, and will in turn
+create an issue with the payload in the body of the issue. You can always
+[customize the payload](#customizing-the-payload) to your liking.
+
+The entire payload will be posted in the issue discussion as a comment
+authored by the GitLab Alert Bot.
+
+NOTE: **Note:**
+In GitLab versions 13.1 and greater, you can configure
+[External Prometheus instances](../metrics/alerts.md#external-prometheus-instances)
+to use this endpoint.
+
+## Setting up generic alerts
+
+To obtain credentials for setting up a generic alerts integration:
+
+- Sign in to GitLab as a user with maintainer [permissions](../../user/permissions.md) for a project.
+- Navigate to the **Operations** page for your project, depending on your installed version of GitLab:
+  - *In GitLab versions 13.1 and greater,* navigate to **Settings > Operations** in your project.
+  - *In GitLab versions prior to 13.1,* navigate to **Settings > Integrations** in your project. GitLab will display a banner encouraging you to enable the Alerts endpoint in **Settings > Operations** instead.
+- Click **Alerts endpoint**.
+- Toggle the **Active** alert setting to display the **URL** and **Authorization Key** for the webhook configuration.
+
+## Customizing the payload
+
+You can customize the payload by sending the following parameters. All fields other than `title` are optional:
+
+| Property | Type | Description |
+| -------- | ---- | ----------- |
+| `title` | String | The title of the incident. Required. |
+| `description` | String | A high-level summary of the problem. |
+| `start_time` | DateTime | The time of the incident. If none is provided, a timestamp of the issue will be used. |
+| `service` | String | The affected service. |
+| `monitoring_tool` | String |  The name of the associated monitoring tool. |
+| `hosts` | String or Array | One or more hosts, as to where this incident occurred. |
+| `severity` | String | The severity of the alert. Must be one of `critical`, `high`, `medium`, `low`, `info`, `unknown`. Default is `critical`. |
+| `fingerprint` | String or Array | The unique identifier of the alert. This can be used to group occurrences of the same alert. |
+| `gitlab_environment_name` | String | The name of the associated GitLab [environment](../../ci/environments/index.md). This can be used to associate your alert to your environment. |
+
+You can also add custom fields to the alert's payload. The values of extra parameters
+are not limited to primitive types, such as strings or numbers, but can be a nested
+JSON object. For example:
+
+```json
+{ "foo": { "bar": { "baz": 42 } } }
+```
+
+TIP: **Payload size:**
+Ensure your requests are smaller than the [payload application limits](../../administration/instance_limits.md#generic-alert-json-payloads).
+
+Example request:
+
+```shell
+curl --request POST \
+  --data '{"title": "Incident title"}' \
+  --header "Authorization: Bearer <authorization_key>" \
+  --header "Content-Type: application/json" \
+  <url>
+```
+
+The `<authorization_key>` and `<url>` values can be found when [setting up generic alerts](#setting-up-generic-alerts).
+
+Example payload:
+
+```json
+{
+  "title": "Incident title",
+  "description": "Short description of the incident",
+  "start_time": "2019-09-12T06:00:55Z",
+  "service": "service affected",
+  "monitoring_tool": "value",
+  "hosts": "value",
+  "severity": "high",
+  "fingerprint": "d19381d4e8ebca87b55cda6e8eee7385",
+  "foo": {
+    "bar": {
+      "baz": 42
+    }
+  }
+}
+```
+
+## Triggering test alerts
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3066) in GitLab Core in 13.2.
+
+After a [project maintainer or owner](#setting-up-generic-alerts)
+[configures generic alerts](#setting-up-generic-alerts), you can trigger a
+test alert to confirm your integration works properly.
+
+1. Sign in as a user with Developer or greater [permissions](../../user/permissions.md).
+1. Navigate to **Settings > Operations** in your project.
+1. Click **Alerts endpoint** to expand the section.
+1. Enter a sample payload in **Alert test payload** (valid JSON is required).
+1. Click **Test alert payload**.
+
+GitLab displays an error or success message, depending on the outcome of your test.
+
+## Automatic grouping of identical alerts **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214557) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2.
+
+In GitLab versions 13.2 and greater, GitLab groups alerts based on their payload.
+When an incoming alert contains the same payload as another alert (excluding the
+`start_time` and `hosts` attributes), GitLab groups these alerts together and
+displays a counter on the
+[Alert Management List](incidents.md)
+and details pages.
+
+If the existing alert is already `resolved`, then a new alert will be created instead.
+
+![Alert Management List](img/alert_list_v13_1.png)
diff --git a/doc/user/project/operations/img/alert_list_v13_1.png b/doc/operations/incident_management/img/alert_list_v13_1.png
index 7a1a5f5191e..7a1a5f5191e 100644
--- a/doc/user/project/operations/img/alert_list_v13_1.png
+++ b/doc/operations/incident_management/img/alert_list_v13_1.png
diff --git a/doc/operations/incident_management/index.md b/doc/operations/incident_management/index.md
index 53a6b47ec4b..6c70d1d9927 100644
--- a/doc/operations/incident_management/index.md
+++ b/doc/operations/incident_management/index.md
@@ -50,7 +50,7 @@ user, but it does not count toward your license limit.
 ## Configure external generic alerts
 
 GitLab can accept alerts from any source through a generic webhook receiver. When
-[configuring the generic alerts integration](../../user/project/integrations/generic_alerts.md),
+[configuring the generic alerts integration](generic_alerts.md),
 GitLab creates a unique endpoint which receives a JSON-formatted, customizable payload.
 
 ## Integrate incidents with Slack
diff --git a/doc/operations/metrics/alerts.md b/doc/operations/metrics/alerts.md
index 2ed8de9396a..90cc70c8e53 100644
--- a/doc/operations/metrics/alerts.md
+++ b/doc/operations/metrics/alerts.md
@@ -78,7 +78,7 @@ Prometheus. The value of this should match the name of your environment in GitLa
 NOTE: **Note:**
 In GitLab versions 13.1 and greater, you can configure your manually configured
 Prometheus server to use the
-[Generic alerts integration](../../user/project/integrations/generic_alerts.md).
+[Generic alerts integration](../incident_management/generic_alerts.md).
 
 ## Trigger actions from alerts **(ULTIMATE)**
 
diff --git a/doc/operations/product_analytics.md b/doc/operations/product_analytics.md
index 96f1a45167b..8f660a16b47 100644
--- a/doc/operations/product_analytics.md
+++ b/doc/operations/product_analytics.md
@@ -33,7 +33,7 @@ To enable it:
 # Instance-wide
 Feature.enable(:product_analytics)
 # or by project
-Feature.enable(:product_analytics, Project.find(<project id>))
+Feature.enable(:product_analytics, Project.find(<project ID>))
 ```
 
 To disable it:
@@ -42,7 +42,7 @@ To disable it:
 # Instance-wide
 Feature.disable(:product_analytics)
 # or by project
-Feature.disable(:product_analytics, Project.find(<project id>))
+Feature.disable(:product_analytics, Project.find(<project ID>))
 ```
 
 ## Access Product Analytics
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index b2020d48d38..3d5180854b5 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -678,7 +678,7 @@ To enable On-demand Scans:
 # Instance-wide
 Feature.enable(:security_on_demand_scans_feature_flag)
 # or by project
-Feature.enable(:security_on_demand_scans_feature_flag, Project.find(<project id>))
+Feature.enable(:security_on_demand_scans_feature_flag, Project.find(<project ID>))
 ```
 
 #### Enable or disable site profiles
@@ -703,7 +703,7 @@ To enable Site Profiles:
 # Instance-wide
 Feature.enable(:security_on_demand_scans_site_profiles_feature_flag)
 # or by project
-Feature.enable(:security_on_demand_scans_site_profiles_feature_flag, Project.find(<project id>))
+Feature.enable(:security_on_demand_scans_site_profiles_feature_flag, Project.find(<project ID>))
 ```
 
 ## Reports
diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md
index f04472a29bb..43041456060 100644
--- a/doc/user/group/iterations/index.md
+++ b/doc/user/group/iterations/index.md
@@ -76,7 +76,7 @@ To enable it:
 # Instance-wide
 Feature.enable(:group_iterations)
 # or by group
-Feature.enable(:group_iterations, Group.find(<group id>))
+Feature.enable(:group_iterations, Group.find(<group ID>))
 ```
 
 To disable it:
@@ -85,7 +85,7 @@ To disable it:
 # Instance-wide
 Feature.disable(:group_iterations)
 # or by group
-Feature.disable(:group_iterations, Group.find(<group id>))
+Feature.disable(:group_iterations, Group.find(<group ID>))
 ```
 
 <!-- ## Troubleshooting
diff --git a/doc/user/group/saml_sso/group_managed_accounts.md b/doc/user/group/saml_sso/group_managed_accounts.md
index 126970ebbb6..2cf27e7c103 100644
--- a/doc/user/group/saml_sso/group_managed_accounts.md
+++ b/doc/user/group/saml_sso/group_managed_accounts.md
@@ -76,7 +76,8 @@ This restriction also applies to projects forked from or to those groups.
 
 Groups with group-managed accounts can disallow forking of projects to destinations outside the group.
 To do so, enable the "Prohibit outer forks" option in **Settings > SAML SSO**.
-When enabled, projects within the group can only be forked to other destinations within the group (including its subgroups).
+When enabled **at the parent group level**, projects within the group can be forked
+only to other destinations within the group (including its subgroups).
 
 ## Credentials inventory for Group-managed accounts **(ULTIMATE)**
 
diff --git a/doc/user/project/integrations/generic_alerts.md b/doc/user/project/integrations/generic_alerts.md
index 42f33e8d670..0e8e082859b 100644
--- a/doc/user/project/integrations/generic_alerts.md
+++ b/doc/user/project/integrations/generic_alerts.md
@@ -1,125 +1,5 @@
 ---
-stage: Monitor
-group: Health
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+redirect_to: '../../../operations/incident_management/generic_alerts.md'
 ---
 
-# Generic alerts integration
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13203) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.4.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/42640) to [GitLab Core](https://about.gitlab.com/pricing/) in 12.8.
-
-GitLab can accept alerts from any source via a generic webhook receiver.
-When you set up the generic alerts integration, a unique endpoint will
-be created which can receive a payload in JSON format, and will in turn
-create an issue with the payload in the body of the issue. You can always
-[customize the payload](#customizing-the-payload) to your liking.
-
-The entire payload will be posted in the issue discussion as a comment
-authored by the GitLab Alert Bot.
-
-NOTE: **Note:**
-In GitLab versions 13.1 and greater, you can configure
-[External Prometheus instances](../../../operations/metrics/alerts.md#external-prometheus-instances)
-to use this endpoint.
-
-## Setting up generic alerts
-
-To obtain credentials for setting up a generic alerts integration:
-
-- Sign in to GitLab as a user with maintainer [permissions](../../permissions.md) for a project.
-- Navigate to the **Operations** page for your project, depending on your installed version of GitLab:
-  - *In GitLab versions 13.1 and greater,* navigate to **Settings > Operations** in your project.
-  - *In GitLab versions prior to 13.1,* navigate to **Settings > Integrations** in your project. GitLab will display a banner encouraging you to enable the Alerts endpoint in **Settings > Operations** instead.
-- Click **Alerts endpoint**.
-- Toggle the **Active** alert setting to display the **URL** and **Authorization Key** for the webhook configuration.
-
-## Customizing the payload
-
-You can customize the payload by sending the following parameters. All fields other than `title` are optional:
-
-| Property | Type | Description |
-| -------- | ---- | ----------- |
-| `title` | String | The title of the incident. Required. |
-| `description` | String | A high-level summary of the problem. |
-| `start_time` | DateTime | The time of the incident. If none is provided, a timestamp of the issue will be used. |
-| `service` | String | The affected service. |
-| `monitoring_tool` | String |  The name of the associated monitoring tool. |
-| `hosts` | String or Array | One or more hosts, as to where this incident occurred. |
-| `severity` | String | The severity of the alert. Must be one of `critical`, `high`, `medium`, `low`, `info`, `unknown`. Default is `critical`. |
-| `fingerprint` | String or Array | The unique identifier of the alert. This can be used to group occurrences of the same alert. |
-| `gitlab_environment_name` | String | The name of the associated GitLab [environment](../../../ci/environments/index.md). This can be used to associate your alert to your environment. |
-
-You can also add custom fields to the alert's payload. The values of extra parameters
-are not limited to primitive types, such as strings or numbers, but can be a nested
-JSON object. For example:
-
-```json
-{ "foo": { "bar": { "baz": 42 } } }
-```
-
-TIP: **Payload size:**
-Ensure your requests are smaller than the [payload application limits](../../../administration/instance_limits.md#generic-alert-json-payloads).
-
-Example request:
-
-```shell
-curl --request POST \
-  --data '{"title": "Incident title"}' \
-  --header "Authorization: Bearer <authorization_key>" \
-  --header "Content-Type: application/json" \
-  <url>
-```
-
-The `<authorization_key>` and `<url>` values can be found when [setting up generic alerts](#setting-up-generic-alerts).
-
-Example payload:
-
-```json
-{
-  "title": "Incident title",
-  "description": "Short description of the incident",
-  "start_time": "2019-09-12T06:00:55Z",
-  "service": "service affected",
-  "monitoring_tool": "value",
-  "hosts": "value",
-  "severity": "high",
-  "fingerprint": "d19381d4e8ebca87b55cda6e8eee7385",
-  "foo": {
-    "bar": {
-      "baz": 42
-    }
-  }
-}
-```
-
-## Triggering test alerts
-
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3066) in GitLab Core in 13.2.
-
-After a [project maintainer or owner](#setting-up-generic-alerts)
-[configures generic alerts](#setting-up-generic-alerts), you can trigger a
-test alert to confirm your integration works properly.
-
-1. Sign in as a user with Developer or greater [permissions](../../../user/permissions.md).
-1. Navigate to **Settings > Operations** in your project.
-1. Click **Alerts endpoint** to expand the section.
-1. Enter a sample payload in **Alert test payload** (valid JSON is required).
-1. Click **Test alert payload**.
-
-GitLab displays an error or success message, depending on the outcome of your test.
-
-## Automatic grouping of identical alerts **(PREMIUM)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214557) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2.
-
-In GitLab versions 13.2 and greater, GitLab groups alerts based on their payload.
-When an incoming alert contains the same payload as another alert (excluding the
-`start_time` and `hosts` attributes), GitLab groups these alerts together and
-displays a counter on the
-[Alert Management List](../../../operations/incident_management/incidents.md)
-and details pages.
-
-If the existing alert is already `resolved`, then a new alert will be created instead.
-
-![Alert Management List](../operations/img/alert_list_v13_1.png)
+This document was moved to [another location](../../../operations/incident_management/generic_alerts.md).
diff --git a/doc/user/project/integrations/overview.md b/doc/user/project/integrations/overview.md
index f179cd6b98e..ffa1167d5a4 100644
--- a/doc/user/project/integrations/overview.md
+++ b/doc/user/project/integrations/overview.md
@@ -39,7 +39,7 @@ Click on the service links to see further configuration instructions and details
 | [Emails on push](emails_on_push.md) | Email the commits and diff of each push to a list of recipients | No |
 | External Wiki | Replaces the link to the internal wiki with a link to an external wiki | No |
 | Flowdock | Flowdock is a collaboration web app for technical teams | No |
-| [Generic alerts](generic_alerts.md) **(ULTIMATE)** | Receive alerts on GitLab from any source | No |
+| [Generic alerts](../../../operations/incident_management/generic_alerts.md) **(ULTIMATE)** | Receive alerts on GitLab from any source | No |
 | [GitHub](github.md) **(PREMIUM)** | Sends pipeline notifications to GitHub | No |
 | [Hangouts Chat](hangouts_chat.md) | Receive events notifications in Google Hangouts Chat | No |
 | [HipChat](hipchat.md) | Private group chat and IM | No |
diff --git a/doc/user/project/integrations/servicenow.md b/doc/user/project/integrations/servicenow.md
new file mode 100644
index 00000000000..d549921b9d9
--- /dev/null
+++ b/doc/user/project/integrations/servicenow.md
@@ -0,0 +1,41 @@
+---
+stage: Create
+group: Ecosystem
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# ServiceNow integration
+
+ServiceNow offers several integrations to help centralize and automate your
+management of GitLab workflows.
+
+## GitLab spoke
+
+With the GitLab spoke in ServiceNow, you can automate actions for GitLab
+projects, groups, users, issues, merge requests, branches, and repositories.
+
+For a full list of features, see the
+[GitLab spoke documentation](https://docs.servicenow.com/bundle/orlando-servicenow-platform/page/administer/integrationhub-store-spokes/concept/gitlab-spoke.html).
+
+You must [configure GitLab as an OAuth2 authentication service provider](../../../integration/oauth_provider.md),
+which involves creating an application and then providing the Application ID
+and Secret in ServiceNow.
+
+## GitLab SCM and Continuous Integration for DevOps
+
+In ServiceNow DevOps, you can integrate with GitLab repositories and GitLab CI/CD
+to centralize your view of GitLab activity and your change management processes.
+You can:
+
+- Track information about activity in GitLab repositories and CI/CD pipelines in
+  ServiceNow.
+- Integrate with GitLab CI/CD pipelines, by automating the creation of change
+  tickets and determining criteria for changes to auto-approve.
+
+For more information, refer to the following ServiceNow resources:
+
+- [ServiceNow DevOps home page](https://www.servicenow.com/products/devops.html)
+- [Install DevOps](https://docs.servicenow.com/bundle/paris-devops/page/product/enterprise-dev-ops/task/activate-dev-ops.html)
+- [Install DevOps Integrations](https://docs.servicenow.com/bundle/paris-devops/page/product/enterprise-dev-ops/task/activate-dev-ops-integrations.html)
+- [GitLab SCM and Continuous Integration for DevOps](https://store.servicenow.com/sn_appstore_store.do#!/store/application/54dc4eacdbc2dcd02805320b7c96191e/)
+- [Model a GitLab CI pipeline in DevOps](https://docs.servicenow.com/bundle/paris-devops/page/product/enterprise-dev-ops/task/model-gitlab-pipeline-dev-ops.html).
diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md
index 7f752b2cc39..bea3faf9af5 100644
--- a/doc/user/project/merge_requests/squash_and_merge.md
+++ b/doc/user/project/merge_requests/squash_and_merge.md
@@ -133,7 +133,7 @@ To enable it:
 # Instance-wide
 Feature.enable(:squash_options)
 # or by project
-Feature.enable(:squash_options, Project.find(<project id>))
+Feature.enable(:squash_options, Project.find(<project ID>))
 ```
 
 To disable it:
@@ -142,7 +142,7 @@ To disable it:
 # Instance-wide
 Feature.disable(:squash_options)
 # or by project
-Feature.disable(:squash_options, Project.find(<project id>))
+Feature.disable(:squash_options, Project.find(<project ID>))
 ```
 
 <!-- ## Troubleshooting