Add latest changes from gitlab-org/gitlab@master

16 files changed, 168 insertions, 98 deletions

diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 42269f780a8..d69eed81c17 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -1075,7 +1075,7 @@ recovery efforts by preventing writes that may conflict with the unreplicated wr
 To enable writes again, an administrator can:
 
 1. [Check](#check-for-data-loss) for data loss.
-1. Attempt to [recover](#recover-missing-data) missing data.
+1. Attempt to [recover](#data-recovery) missing data.
 1. Either [enable writes](#enable-writes-or-accept-data-loss) in the virtual storage or
    [accept data loss](#enable-writes-or-accept-data-loss) if necessary, depending on the version of
    GitLab.
@@ -1169,17 +1169,6 @@ Virtual storage: default
 To check a project's repository checksums across on all Gitaly nodes, run the
 [replicas Rake task](../raketasks/praefect.md#replica-checksums) on the main GitLab node.
 
-### Recover missing data
-
-The Praefect `reconcile` sub-command can be used to recover unreplicated changes from another replica.
-The source must be on a later version than the target storage.
-
-```shell
-sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml reconcile -virtual <virtual-storage> -reference <up-to-date-storage> -target <outdated-storage> -f
-```
-
-Refer to [Gitaly node recovery](#gitaly-node-recovery) section for more details on the `reconcile` sub-command.
-
 ### Enable writes or accept data loss
 
 Praefect provides the following subcommands to re-enable writes:
@@ -1203,31 +1192,53 @@ Praefect provides the following subcommands to re-enable writes:
 
 CAUTION: **Caution:**
 `accept-dataloss` causes permanent data loss by overwriting other versions of the repository. Data
-[recovery efforts](#recover-missing-data) must be performed before using it.
+[recovery efforts](#data-recovery) must be performed before using it.
+
+## Data recovery
+
+If a Gitaly node fails replication jobs for any reason, it ends up hosting outdated versions of
+the affected repositories. Praefect provides tools for automatically or manually reconciling
+the outdated repositories in order to bring them fully up to date again.
 
-## Gitaly node recovery
+### Automatic reconciliation
 
-When a secondary Gitaly node fails and is no longer able to replicate changes, it starts
-to drift from the primary Gitaly node. If the failed Gitaly node eventually recovers,
-it needs to be reconciled with the primary Gitaly node. The primary Gitaly node is considered
-the single source of truth for the state of a shard.
+> [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/2717) in GitLab 13.4.
 
-The Praefect `reconcile` sub-command allows for the manual reconciliation between a secondary
-Gitaly node and the current primary Gitaly node.
+Praefect automatically reconciles repositories that are not up to date. By default, this is done every
+five minutes. For each outdated repository on a healthy Gitaly node, the Praefect picks a
+random, fully up to date replica of the repository on another healthy Gitaly node to replicate from. A
+replication job is scheduled only if there are no other replication jobs pending for the target
+repository.
 
-Run the following command on the Praefect server after all placeholders
-(`<virtual-storage>` and `<target-storage>`) have been replaced:
+The reconciliation frequency can be changed via the configuration. The value can be any valid
+[Go duration value](https://golang.org/pkg/time/#ParseDuration). Values below 0 disable the feature.
+
+Examples:
+
+```ruby
+praefect['reconciliation_scheduling_interval'] = '5m' # the default value
+```
+
+```ruby
+praefect['reconciliation_scheduling_interval'] = '30s' # reconcile every 30 seconds
+```
+
+```ruby
+praefect['reconciliation_scheduling_interval'] = '0' # disable the feature
+```
+
+### Manual reconciliation
+
+The Praefect `reconcile` sub-command allows for the manual reconciliation between two Gitaly nodes. The
+command replicates every repository on a later version on the reference storage to the target storage.
 
 ```shell
-sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml reconcile -virtual <virtual-storage> -target <target-storage>
+sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml reconcile -virtual <virtual-storage> -reference <up-to-date-storage> -target <outdated-storage> -f
 ```
 
 - Replace the placeholder `<virtual-storage>` with the virtual storage containing the Gitaly node storage to be checked.
-- Replace the placeholder `<target-storage>` with the Gitaly storage name.
-
-The command will return a list of repositories that were found to be
-inconsistent against the current primary. Each of these inconsistencies will
-also be logged with an accompanying replication job ID.
+- Replace the placeholder `<up-to-date-storage>` with the Gitaly storage name containing up to date repositories.
+- Replace the placeholder `<outdated-storage>` with the Gitaly storage name containing outdated repositories.
 
 ## Migrate existing repositories to Gitaly Cluster
 
diff --git a/doc/api/search.md b/doc/api/search.md
index 4c87a826ca8..532ea0aa3ac 100644
--- a/doc/api/search.md
+++ b/doc/api/search.md
@@ -397,6 +397,7 @@ GET /groups/:id/search
 | `id`                | integer/string   | yes        | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user                |
 | `scope`       | string   | yes        | The scope to search in                |
 | `search`      | string   | yes        | The search query  |
+| `state`       | string   | no        | Filtering by state, currently only supported for issues and merge requests. It is ignored for other scopes  |
 
 Search the expression within the specified scope. Currently these scopes are supported: projects, issues, merge_requests, milestones, users.
 
@@ -741,6 +742,7 @@ GET /projects/:id/search
 | `scope`       | string   | yes        | The scope to search in                |
 | `search`      | string   | yes        | The search query  |
 | `ref`         | string   | no         | The name of a repository branch or tag to search on. The project's default branch is used by default. This is only applicable for scopes: commits, blobs, and wiki_blobs.  |
+| `state`       | string   | no        | Filtering by state, currently only supported for issues and merge requests. It is ignored for other scopes  |
 
 Search the expression within the specified scope. Currently these scopes are supported: issues, merge_requests, milestones, notes, wiki_blobs, commits, blobs, users.
 
diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index 07f784b6534..50f7d5252d8 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -60,7 +60,7 @@ Caches:
 - Are disabled if not defined globally or per job (using `cache:`).
 - Are available for all jobs in your `.gitlab-ci.yml` if enabled globally.
 - Can be used in subsequent pipelines by the same job in which the cache was created (if not defined globally).
-- Are stored where the Runner is installed **and** uploaded to S3 if [distributed cache is enabled](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching).
+- Are stored where GitLab Runner is installed **and** uploaded to S3 if [distributed cache is enabled](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching).
 - If defined per job, are used:
   - By the same job in a subsequent pipeline.
   - By subsequent jobs in the same pipeline, if they have identical dependencies.
@@ -80,33 +80,33 @@ can't link to files outside it.
 ## Good caching practices
 
 We have the cache from the perspective of the developers (who consume a cache
-within the job) and the cache from the perspective of the Runner. Depending on
-which type of Runner you are using, cache can act differently.
+within the job) and the cache from the perspective of the runner. Depending on
+which type of runner you are using, cache can act differently.
 
 From the perspective of the developer, to ensure maximum availability of the
 cache, when declaring `cache` in your jobs, use one or a mix of the following:
 
-- [Tag your Runners](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
+- [Tag your runners](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
   that share their cache.
-- [Use sticky Runners](../runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
+- [Use sticky runners](../runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
   that will be only available to a particular project.
 - [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (for example,
   different caches on each branch). For that, you can take advantage of the
   [CI/CD predefined variables](../variables/README.md#predefined-environment-variables).
 
 TIP: **Tip:**
-Using the same Runner for your pipeline, is the most simple and efficient way to
+Using the same runner for your pipeline, is the most simple and efficient way to
 cache files in one stage or pipeline, and pass this cache to subsequent stages
 or pipelines in a guaranteed manner.
 
-From the perspective of the Runner, in order for cache to work effectively, one
+From the perspective of the runner, in order for cache to work effectively, one
 of the following must be true:
 
-- Use a single Runner for all your jobs.
-- Use multiple Runners (in autoscale mode or not) that use
+- Use a single runner for all your jobs.
+- Use multiple runners (in autoscale mode or not) that use
   [distributed caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching),
-  where the cache is stored in S3 buckets (like shared Runners on GitLab.com).
-- Use multiple Runners (not in autoscale mode) of the same architecture that
+  where the cache is stored in S3 buckets (like shared runners on GitLab.com).
+- Use multiple runners (not in autoscale mode) of the same architecture that
   share a common network-mounted directory (using NFS or something similar)
   where the cache will be stored.
 
@@ -364,27 +364,27 @@ be prepared to regenerate any cached files in each job that needs them.
 
 Assuming you have properly [defined `cache` in `.gitlab-ci.yml`](../yaml/README.md#cache)
 according to your workflow, the availability of the cache ultimately depends on
-how the Runner has been configured (the executor type and whether different
-Runners are used for passing the cache between jobs).
+how the runner has been configured (the executor type and whether different
+runners are used for passing the cache between jobs).
 
 ### Where the caches are stored
 
-Since the Runner is the one responsible for storing the cache, it's essential
+Since the runner is the one responsible for storing the cache, it's essential
 to know **where** it's stored. All the cache paths defined under a job in
 `.gitlab-ci.yml` are archived in a single `cache.zip` file and stored in the
-Runner's configured cache location. By default, they are stored locally in the
-machine where the Runner is installed and depends on the type of the executor.
+runner's configured cache location. By default, they are stored locally in the
+machine where the runner is installed and depends on the type of the executor.
 
 | GitLab Runner executor | Default path of the cache |
 | ---------------------- | ------------------------- |
 | [Shell](https://docs.gitlab.com/runner/executors/shell.html) | Locally, stored under the `gitlab-runner` user's home directory: `/home/gitlab-runner/cache/<user>/<project>/<cache-key>/cache.zip`. |
 | [Docker](https://docs.gitlab.com/runner/executors/docker.html) | Locally, stored under [Docker volumes](https://docs.gitlab.com/runner/executors/docker.html#the-builds-and-cache-storage): `/var/lib/docker/volumes/<volume-id>/_data/<user>/<project>/<cache-key>/cache.zip`. |
-| [Docker machine](https://docs.gitlab.com/runner/executors/docker_machine.html) (autoscale Runners) | Behaves the same as the Docker executor. |
+| [Docker machine](https://docs.gitlab.com/runner/executors/docker_machine.html) (autoscale runners) | Behaves the same as the Docker executor. |
 
 ### How archiving and extracting works
 
 In the most simple scenario, consider that you use only one machine where the
-Runner is installed, and all jobs of your project run on the same host.
+runner is installed, and all jobs of your project run on the same host.
 
 Let's see the following example of two jobs that belong to two consecutive
 stages:
@@ -426,17 +426,17 @@ Here's what happens behind the scenes:
 1. `after_script` is executed.
 1. `cache` runs and the `vendor/` directory is zipped into `cache.zip`.
    This file is then saved in the directory based on the
-   [Runner's setting](#where-the-caches-are-stored) and the `cache: key`.
+   [runner's setting](#where-the-caches-are-stored) and the `cache: key`.
 1. `job B` runs.
 1. The cache is extracted (if found).
 1. `before_script` is executed.
 1. `script` is executed.
 1. Pipeline finishes.
 
-By using a single Runner on a single machine, you'll not have the issue where
-`job B` might execute on a Runner different from `job A`, thus guaranteeing the
+By using a single runner on a single machine, you'll not have the issue where
+`job B` might execute on a runner different from `job A`, thus guaranteeing the
 cache between stages. That will only work if the build goes from stage `build`
-to `test` in the same Runner/machine, otherwise, you [might not have the cache
+to `test` in the same runner/machine, otherwise, you [might not have the cache
 available](#cache-mismatch).
 
 During the caching process, there's also a couple of things to consider:
@@ -448,13 +448,13 @@ During the caching process, there's also a couple of things to consider:
   their cache.
 - When extracting the cache from `cache.zip`, everything in the zip file is
   extracted in the job's working directory (usually the repository which is
-  pulled down), and the Runner doesn't mind if the archive of `job A` overwrites
+  pulled down), and the runner doesn't mind if the archive of `job A` overwrites
   things in the archive of `job B`.
 
-The reason why it works this way is because the cache created for one Runner
+The reason why it works this way is because the cache created for one runner
 often will not be valid when used by a different one which can run on a
 **different architecture** (e.g., when the cache includes binary files). And
-since the different steps might be executed by Runners running on different
+since the different steps might be executed by runners running on different
 machines, it is a safe default.
 
 ### Cache mismatch
@@ -464,17 +464,17 @@ mismatch and a few ideas how to fix it.
 
 | Reason of a cache mismatch | How to fix it |
 | -------------------------- | ------------- |
-| You use multiple standalone Runners (not in autoscale mode) attached to one project without a shared cache | Use only one Runner for your project or use multiple Runners with distributed cache enabled |
-| You use Runners in autoscale mode without a distributed cache enabled | Configure the autoscale Runner to use a distributed cache |
-| The machine the Runner is installed on is low on disk space or, if you've set up distributed cache, the S3 bucket where the cache is stored doesn't have enough space | Make sure you clear some space to allow new caches to be stored. Currently, there's no automatic way to do this. |
+| You use multiple standalone runners (not in autoscale mode) attached to one project without a shared cache | Use only one runner for your project or use multiple runners with distributed cache enabled |
+| You use runners in autoscale mode without a distributed cache enabled | Configure the autoscale runner to use a distributed cache |
+| The machine the runner is installed on is low on disk space or, if you've set up distributed cache, the S3 bucket where the cache is stored doesn't have enough space | Make sure you clear some space to allow new caches to be stored. Currently, there's no automatic way to do this. |
 | You use the same `key` for jobs where they cache different paths. | Use different cache keys to that the cache archive is stored to a different location and doesn't overwrite wrong caches. |
 
 Let's explore some examples.
 
 #### Examples
 
-Let's assume you have only one Runner assigned to your project, so the cache
-will be stored in the Runner's machine by default. If two jobs, A and B,
+Let's assume you have only one runner assigned to your project, so the cache
+will be stored in the runner's machine by default. If two jobs, A and B,
 have the same cache key, but they cache different paths, cache B would overwrite
 cache A, even if their `paths` don't match:
 
@@ -513,7 +513,7 @@ job B:
 
 To fix that, use different `keys` for each job.
 
-In another case, let's assume you have more than one Runners assigned to your
+In another case, let's assume you have more than one runner assigned to your
 project, but the distributed cache is not enabled. The second time the
 pipeline is run, we want `job A` and `job B` to re-use their cache (which in this case
 will be different):
@@ -542,11 +542,11 @@ job B:
 
 In that case, even if the `key` is different (no fear of overwriting), you
 might experience that the cached files "get cleaned" before each stage if the
-jobs run on different Runners in the subsequent pipelines.
+jobs run on different runners in the subsequent pipelines.
 
 ## Clearing the cache
 
-GitLab Runners use [cache](../yaml/README.md#cache) to speed up the execution
+Runners use [cache](../yaml/README.md#cache) to speed up the execution
 of your jobs by reusing existing data. This however, can sometimes lead to an
 inconsistent behavior.
 
@@ -565,9 +565,9 @@ If you want to avoid editing `.gitlab-ci.yml`, you can easily clear the cache
 via GitLab's UI:
 
 1. Navigate to your project's **CI/CD > Pipelines** page.
-1. Click on the **Clear Runner caches** button to clean up the cache.
+1. Click on the **Clear runner caches** button to clean up the cache.
 
-   ![Clear Runners cache](img/clear_runners_cache.png)
+   ![Clear runner caches](img/clear_runners_cache.png)
 
 1. On the next push, your CI/CD job will use a new cache.
 
diff --git a/doc/ci/unit_test_reports.md b/doc/ci/unit_test_reports.md
index d1bb8f11c0f..5a59a175a89 100644
--- a/doc/ci/unit_test_reports.md
+++ b/doc/ci/unit_test_reports.md
@@ -81,6 +81,8 @@ merge request widget.
 
 To make the Unit test report output files browsable, include them with the
 [`artifacts:paths`](yaml/README.md#artifactspaths) keyword as well, as shown in the [Ruby example](#ruby-example).
+To upload the report even if the job fails (for example if the tests do not pass), use the [`artifacts:when:always`](yaml/README.md#artifactswhen)
+keyword.
 
 NOTE: **Note:**
 You cannot have multiple tests with the same name and class in your JUnit report format XML file.
diff --git a/doc/development/telemetry/usage_ping.md b/doc/development/telemetry/usage_ping.md
index 08e862fba5f..2314661e511 100644
--- a/doc/development/telemetry/usage_ping.md
+++ b/doc/development/telemetry/usage_ping.md
@@ -377,6 +377,56 @@ Recommendations:
 - Use a [feature flag](../../operations/feature_flags.md) to have a control over the impact when
   adding new metrics.
 
+##### Known events in usage data payload
+
+All events added in [`known_events.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events.yml) are automatically added to usage data generation under the `redis_hll_counters` key. This column is stored in [version-app as a JSON](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/db/schema.rb#L209).
+For each event we add metrics for the weekly and monthly time frames, and totals for each where applicable:
+
+- `#{event_name}_weekly` data for 7 days for daily [aggregation](#adding-new-events) events and data for last complete week for weekly [aggregation](#adding-new-events) events.
+- `#{event_name}_monthly` data for 28 days for daily [aggregation](#adding-new-events) events and data for last 4 complete weeks for weekly [aggregation](#adding-new-events) events.
+- `#{category}_total_unique_counts_weekly` total unique counts for events in same category for last 7 days or last complete week, if events are in the same Redis slot and if we have more than one metric.
+- `#{event_name}_weekly` - Data for 7 days for daily [aggregation](#adding-new-events) events and data for the last complete week for weekly [aggregation](#adding-new-events) events.
+- `#{event_name}_monthly` - Data for 28 days for daily [aggregation](#adding-new-events) events and data for the last 4 complete weeks for weekly [aggregation](#adding-new-events) events.
+- `#{category}_total_unique_counts_weekly` - Total unique counts for events in the same category for the last 7 days or the last complete week, if events are in the same Redis slot and we have more than one metric.
+- `#{event_name}_weekly`: Data for 7 days for daily [aggregation](#adding-new-events) events and data for last complete week for weekly [aggregation](#adding-new-events) events.
+- `#{event_name}_monthly`: Data for 28 days for daily [aggregation](#adding-new-events) events and data for last 4 complete weeks for weekly [aggregation](#adding-new-events) events.
+- `#{category}_total_unique_counts_weekly` total unique counts for events in same category for last 7 days or last complete week, if events are in the same Redis slot and if we have more than one metric.
+- `#{event_name}_weekly`: Data for 7 days for daily [aggregation](#adding-new-events) events and data for the last complete week for weekly [aggregation](#adding-new-events) events.
+- `#{event_name}_monthly`: Data for 28 days for daily [aggregation](#adding-new-events) events and data for the last 4 complete weeks for weekly [aggregation](#adding-new-events) events.
+- `#{category}_total_unique_counts_weekly`: Total unique counts for events in the same category for the last 7 days or the last complete week, if events are in the same Redis slot and we have more than one metric.
+- `#{category}_total_unique_counts_monthly`: Total unique counts for events in same category for the last 28 days or the last 4 complete weeks, if events are in the same Redis slot and we have more than one metric.
+
+Example of `redis_hll_counters` data:
+
+```ruby
+{:redis_hll_counters=>
+  {"compliance"=>
+    {"g_compliance_dashboard_weekly"=>0,
+     "g_compliance_dashboard_monthly"=>0,
+     "g_compliance_audit_events_weekly"=>0,
+     "g_compliance_audit_events_monthly"=>0,
+     "compliance_total_unique_counts_weekly"=>0,
+     "compliance_total_unique_counts_monthly"=>0},
+   "analytics"=>
+    {"g_analytics_contribution_weekly"=>0,
+     "g_analytics_contribution_monthly"=>0,
+     "g_analytics_insights_weekly"=>0,
+     "g_analytics_insights_monthly"=>0,
+     "analytics_total_unique_counts_weekly"=>0,
+     "analytics_total_unique_counts_monthly"=>0},
+   "ide_edit"=>
+    {"g_edit_by_web_ide_weekly"=>0,
+     "g_edit_by_web_ide_monthly"=>0,
+     "g_edit_by_sfe_weekly"=>0,
+     "g_edit_by_sfe_monthly"=>0,
+     "ide_edit_total_unique_counts_weekly"=>0,
+     "ide_edit_total_unique_counts_monthly"=>0},
+   "search"=>
+    {"i_search_total_weekly"=>0, "i_search_total_monthly"=>0, "i_search_advanced_weekly"=>0, "i_search_advanced_monthly"=>0, "i_search_paid_weekly"=>0, "i_search_paid_monthly"=>0, "search_total_unique_counts_weekly"=>0, "search_total_unique_counts_monthly"=>0},
+   "source_code"=>{"wiki_action_weekly"=>0, "wiki_action_monthly"=>0}
+ }
+```
+
 Example usage:
 
 ```ruby
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 84311b86afa..85d7e56ea5d 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -42,10 +42,10 @@ information directly in the merge request.
 
 To enable Container Scanning in your pipeline, you need the following:
 
-- [GitLab Runner](https://docs.gitlab.com/runner/) with the [Docker](https://docs.gitlab.com/runner/executors/docker.html)
-  or [Kubernetes](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
-- Docker `18.09.03` or higher installed on the same computer as the Runner. If you're using the
-  shared Runners on GitLab.com, then this is already the case.
+- [GitLab Runner](https://docs.gitlab.com/runner/) with the [`docker`](https://docs.gitlab.com/runner/executors/docker.html)
+  or [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
+- Docker `18.09.03` or higher installed on the same computer as the runner. If you're using the
+  shared runners on GitLab.com, then this is already the case.
 - [Build and push](../../packages/container_registry/index.md#container-registry-examples-with-gitlab-cicd)
   your Docker image to your project's container registry. The name of the Docker image should use
   the following [predefined environment variables](../../../ci/variables/predefined_variables.md):
@@ -221,8 +221,8 @@ To use Container Scanning in an offline environment, you need:
 
 NOTE: **Note:**
 GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy),
-meaning the Runner tries to pull Docker images from the GitLab container registry even if a local
-copy is available. GitLab Runner's [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
+meaning the runner tries to pull Docker images from the GitLab container registry even if a local
+copy is available. The GitLab Runner [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
 in an offline environment if you prefer using only locally available Docker images. However, we
 recommend keeping the pull policy setting to `always` if not in an offline environment, as this
 enables the use of updated scanners in your CI/CD pipelines.
@@ -421,7 +421,7 @@ Read more about the [solutions for vulnerabilities](../index.md#solutions-for-vu
 
 ### `docker: Error response from daemon: failed to copy xattrs`
 
-When the GitLab Runner uses the Docker executor and NFS is used
+When the runner uses the `docker` executor and NFS is used
 (for example, `/var/lib/docker` is on an NFS mount), Container Scanning might fail with
 an error like the following:
 
@@ -430,6 +430,6 @@ docker: Error response from daemon: failed to copy xattrs: failed to set xattr "
 ```
 
 This is a result of a bug in Docker which is now [fixed](https://github.com/containerd/continuity/pull/138 "fs: add WithAllowXAttrErrors CopyOpt").
-To prevent the error, ensure the Docker version that the Runner is using is
+To prevent the error, ensure the Docker version that the runner is using is
 `18.09.03` or higher. For more information, see
 [issue #10241](https://gitlab.com/gitlab-org/gitlab/-/issues/10241 "Investigate why Container Scanning is not working with NFS mounts").
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index 13dc001220c..960f7053106 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -566,8 +566,8 @@ To use DAST in an offline environment, you need:
 
 NOTE: **Note:**
 GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy),
-meaning the Runner tries to pull Docker images from the GitLab container registry even if a local
-copy is available. GitLab Runner's [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
+meaning the runner tries to pull Docker images from the GitLab container registry even if a local
+copy is available. The GitLab Runner [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
 in an offline environment if you prefer using only locally available Docker images. However, we
 recommend keeping the pull policy setting to `always` if not in an offline environment, as this
 enables the use of updated scanners in your CI/CD pipelines.
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index a39fbd43167..5cce336d04c 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -43,10 +43,10 @@ The results are sorted by the severity of the vulnerability:
 To run Dependency Scanning jobs, by default, you need GitLab Runner with the
 [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
 [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
-If you're using the shared Runners on GitLab.com, this is enabled by default.
+If you're using the shared runners on GitLab.com, this is enabled by default.
 
 CAUTION: **Caution:**
-If you use your own Runners, make sure your installed version of Docker
+If you use your own runners, make sure your installed version of Docker
 is **not** `19.03.0`. See [troubleshooting information](#error-response-from-daemon-error-processing-tar-file-docker-tar-relocation-error) for details.
 
 ## Supported languages and package managers
@@ -362,8 +362,8 @@ Here are the requirements for using Dependency Scanning in an offline environmen
 
 NOTE: **Note:**
 GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy),
-meaning the Runner tries to pull Docker images from the GitLab container registry even if a local
-copy is available. GitLab Runner's [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
+meaning the runner tries to pull Docker images from the GitLab container registry even if a local
+copy is available. The GitLab Runner [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
 in an offline environment if you prefer using only locally available Docker images. However, we
 recommend keeping the pull policy setting to `always` if not in an offline environment, as this
 enables the use of updated scanners in your CI/CD pipelines.
diff --git a/doc/user/application_security/offline_deployments/index.md b/doc/user/application_security/offline_deployments/index.md
index a5cf93f9448..ea7c5e23d2a 100644
--- a/doc/user/application_security/offline_deployments/index.md
+++ b/doc/user/application_security/offline_deployments/index.md
@@ -96,7 +96,7 @@ above. You can find more information at each of the pages below:
 
 To use many GitLab features, including
 [security scans](../index.md#working-in-an-offline-environment)
-and [Auto DevOps](../../../topics/autodevops/index.md), the GitLab Runner must be able to fetch the
+and [Auto DevOps](../../../topics/autodevops/index.md), the runner must be able to fetch the
 relevant Docker images.
 
 The process for making these images available without direct access to the public internet
@@ -124,7 +124,7 @@ The pipeline downloads the Docker images needed for the Security Scanners and sa
 [job artifacts](../../../ci/pipelines/job_artifacts.md) or pushes them to the [Container Registry](../../packages/container_registry/index.md)
 of the project where the pipeline is executed. These archives can be transferred to another location
 and [loaded](https://docs.docker.com/engine/reference/commandline/load/) in a Docker daemon.
-This method requires a GitLab Runner with access to both `gitlab.com` (including
+This method requires a runner with access to both `gitlab.com` (including
 `registry.gitlab.com`) and the local offline instance. This runner must run in
 [privileged mode](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode)
 to be able to use the `docker` command inside the jobs. This runner can be installed in a DMZ or on
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index 2b717157259..a4fc3c9e638 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -43,16 +43,16 @@ A pipeline consists of multiple jobs, including SAST and DAST scanning. If any j
 
 ## Requirements
 
-To run SAST jobs, by default, you need a GitLab Runner with the
+To run SAST jobs, by default, you need GitLab Runner with the
 [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
 [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
-If you're using the shared Runners on GitLab.com, this is enabled by default.
+If you're using the shared runners on GitLab.com, this is enabled by default.
 
 CAUTION: **Caution:**
 Our SAST jobs require a Linux container type. Windows containers are not yet supported.
 
 CAUTION: **Caution:**
-If you use your own Runners, make sure the Docker version installed
+If you use your own runners, make sure the Docker version installed
 is **not** `19.03.0`. See [troubleshooting information](#error-response-from-daemon-error-processing-tar-file-docker-tar-relocation-error) for details.
 
 ## Supported languages and frameworks
@@ -476,14 +476,14 @@ run successfully. For more information, see [Offline environments](../offline_de
 
 To use SAST in an offline environment, you need:
 
-- A GitLab Runner with the [`docker` or `kubernetes` executor](#requirements).
+- GitLab Runner with the [`docker` or `kubernetes` executor](#requirements).
 - A Docker Container Registry with locally available copies of SAST [analyzer](https://gitlab.com/gitlab-org/security-products/analyzers) images.
 - Configure certificate checking of packages (optional).
 
 NOTE: **Note:**
 GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy),
-meaning the Runner tries to pull Docker images from the GitLab container registry even if a local
-copy is available. GitLab Runner's [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
+meaning the runner tries to pull Docker images from the GitLab container registry even if a local
+copy is available. The GitLab Runner [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
 in an offline environment if you prefer using only locally available Docker images. However, we
 recommend keeping the pull policy setting to `always` if not in an offline environment, as this
 enables the use of updated scanners in your CI/CD pipelines.
diff --git a/doc/user/application_security/secret_detection/index.md b/doc/user/application_security/secret_detection/index.md
index 1089bbfc8c8..f3e411cdc16 100644
--- a/doc/user/application_security/secret_detection/index.md
+++ b/doc/user/application_security/secret_detection/index.md
@@ -37,13 +37,13 @@ GitLab displays identified secrets visibly in a few places:
 To run Secret Detection jobs, by default, you need GitLab Runner with the
 [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
 [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
-If you're using the shared Runners on GitLab.com, this is enabled by default.
+If you're using the shared runners on GitLab.com, this is enabled by default.
 
 CAUTION: **Caution:**
 Our Secret Detection jobs currently expect a Linux container type. Windows containers are not yet supported.
 
 CAUTION: **Caution:**
-If you use your own Runners, make sure the Docker version installed
+If you use your own runners, make sure the Docker version installed
 is **not** `19.03.0`. See [troubleshooting information](../sast#error-response-from-daemon-error-processing-tar-file-docker-tar-relocation-error) for details.
 
 ### Making Secret Detection available to all GitLab tiers
diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md
index 07b4eef906f..51d9b4f45cd 100644
--- a/doc/user/application_security/security_dashboard/index.md
+++ b/doc/user/application_security/security_dashboard/index.md
@@ -35,7 +35,7 @@ To use the instance, group, project, or pipeline security dashboard:
    the [supported reports](#supported-reports).
 1. The configured jobs must use the [new `reports` syntax](../../../ci/pipelines/job_artifacts.md#artifactsreports).
 1. [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or newer must be used.
-   If you're using the shared Runners on GitLab.com, this is already the case.
+   If you're using the shared runners on GitLab.com, this is already the case.
 
 ## Pipeline Security
 
diff --git a/doc/user/compliance/license_compliance/index.md b/doc/user/compliance/license_compliance/index.md
index d51b6484fd9..79c2d97b972 100644
--- a/doc/user/compliance/license_compliance/index.md
+++ b/doc/user/compliance/license_compliance/index.md
@@ -616,8 +616,8 @@ To use License Compliance in an offline environment, you need:
 
 NOTE: **Note:**
 GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy),
-meaning the Runner tries to pull Docker images from the GitLab container registry even if a local
-copy is available. GitLab Runner's [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
+meaning the runner tries to pull Docker images from the GitLab container registry even if a local
+copy is available. The GitLab Runner [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
 in an offline environment if you prefer using only locally available Docker images. However, we
 recommend keeping the pull policy setting to `always` if not in an offline environment, as this
 enables the use of updated scanners in your CI/CD pipelines.
diff --git a/doc/user/markdown.md b/doc/user/markdown.md
index 12d65f75b37..5822c728e08 100644
--- a/doc/user/markdown.md
+++ b/doc/user/markdown.md
@@ -438,6 +438,11 @@ GFM recognizes the following:
 | commit range comparison         | `9ba12248...b19a04f5`      | `namespace/project@9ba12248...b19a04f5` | `project@9ba12248...b19a04f5`  |
 | repository file references      | `[README](doc/README)`     |                                         |                                |
 | repository file line references | `[README](doc/README#L13)` |                                         |                                |
+| [alert](../operations/incident_management/alerts.md) | `^alert#123` | `namespace/project^alert#123`    | `project^alert#123`            |
+
+For example, referencing an issue by using `#123` will format the output as a link
+to issue number 123 with text `#123`. Likewise, a link to issue number 123 will be
+recognized and formatted with text `#123`.
 
 In addition to this, links to some objects are also recognized and formatted. Some examples of these are:
 
diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md
index d692343196e..8146f39ef87 100644
--- a/doc/user/project/deploy_boards.md
+++ b/doc/user/project/deploy_boards.md
@@ -81,8 +81,8 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
    [OpenShift docs](https://docs.openshift.com/container-platform/3.7/dev_guide/deployments/kubernetes_deployments.html#kubernetes-deployments-vs-deployment-configurations)
    and [GitLab issue #4584](https://gitlab.com/gitlab-org/gitlab/-/issues/4584).
 
-1. [Configure GitLab Runner](../../ci/runners/README.md) with the [Docker](https://docs.gitlab.com/runner/executors/docker.html) or
-   [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html) executor.
+1. [Configure GitLab Runner](../../ci/runners/README.md) with the [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
+   [`kubernetes`](https://docs.gitlab.com/runner/executors/kubernetes.html) executor.
 1. Configure the [Kubernetes integration](clusters/index.md) in your project for the
    cluster. The Kubernetes namespace is of particular note as you will need it
    for your deployment scripts (exposed by the `KUBE_NAMESPACE` env variable).
diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md
index d79e5a184ff..d31e42e270e 100644
--- a/doc/user/project/web_ide/index.md
+++ b/doc/user/project/web_ide/index.md
@@ -236,12 +236,12 @@ below.
 
 CAUTION: **Warning:**
 Interactive Web Terminals for the Web IDE is currently in **Beta**.
-Shared Runners [do not yet support Interactive Web Terminals](https://gitlab.com/gitlab-org/gitlab/-/issues/24674),
-so you would need to use your own private Runner(s) to make use of this feature.
+Shared runners [do not yet support Interactive Web Terminals](https://gitlab.com/gitlab-org/gitlab/-/issues/24674),
+so you would need to use your own private runner to make use of this feature.
 
 [Interactive Web Terminals](../../../ci/interactive_web_terminal/index.md)
 give the project [Maintainers](../../permissions.md#project-members-permissions)
-user access to a terminal to interact with the Runner directly from
+user access to a terminal to interact with the runner directly from
 GitLab, including through the Web IDE.
 
 ### Runner configuration
@@ -249,7 +249,7 @@ GitLab, including through the Web IDE.
 Some things need to be configured in the runner for the interactive web terminal
 to work:
 
-- The Runner needs to have
+- The runner needs to have
   [`[session_server]` configured properly](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section).
   This section requires at least a `session_timeout` value (which defaults to 1800
   seconds) and a `listen_address` value. If `advertise_address` is not defined, `listen_address` is used.
@@ -346,7 +346,7 @@ environment.
 NOTE: **Note:**
 Only file changes in the Web IDE are synced to the terminal.
 Changes made in the terminal are **not** synced to the Web IDE.
-This feature is only available for Kubernetes Runners.
+This feature is only available for Kubernetes runners.
 
 To enable file syncing to the web terminal, the `.gitlab/.gitlab-webide.yml`
 file needs to have a `webide-file-sync` service configured. Here is an example
@@ -373,7 +373,7 @@ terminal:
   more information.
 - `$CI_PROJECT_DIR` is a
   [predefined environment variable](../../../ci/variables/predefined_variables.md)
-  for GitLab Runners. This is where your project's repository will be.
+  for GitLab Runner. This is where your project's repository will be.
 
 Once you have configured the web terminal for file syncing, then when the web
 terminal is started, a **Terminal** status will be visible in the status bar.