Add latest changes from gitlab-org/gitlab@master

13 files changed, 35 insertions, 37 deletions

diff --git a/doc/development/code_intelligence/index.md b/doc/development/code_intelligence/index.md
index 3a8845084c3..a89730383e4 100644
--- a/doc/development/code_intelligence/index.md
+++ b/doc/development/code_intelligence/index.md
@@ -35,8 +35,8 @@ sequenceDiagram
     Workhorse-->>-Runner: request results
 ```
 
-1. The CI/CD job generates a document in an LSIF format (usually `dump.lsif`) using [an
-   indexer](https://lsif.dev) for the language of a project. The format
+1. The CI/CD job generates a document in an LSIF format (usually `dump.lsif`) using 
+   [an indexer](https://lsif.dev) for the language of a project. The format
    [describes](https://github.com/sourcegraph/sourcegraph/blob/main/doc/code_intelligence/explanations/writing_an_indexer.md)
    interactions between a method or function and its definitions or references. The
    document is marked to be stored as an LSIF report artifact.
diff --git a/doc/development/database/client_side_connection_pool.md b/doc/development/database/client_side_connection_pool.md
index dc52a551407..3cd0e836a8d 100644
--- a/doc/development/database/client_side_connection_pool.md
+++ b/doc/development/database/client_side_connection_pool.md
@@ -10,8 +10,8 @@ Ruby processes accessing the database through
 ActiveRecord, automatically calculate the connection-pool size for the
 process based on the concurrency.
 
-Because of the way [Ruby on Rails manages database
-connections](#connection-lifecycle), it is important that we have at
+Because of the way [Ruby on Rails manages database connections](#connection-lifecycle), 
+it is important that we have at
 least as many connections as we have threads. While there is a 'pool'
 setting in [`database.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/database.yml.postgresql), it is not very practical because you need to
 maintain it in tandem with the number of application threads. For this
@@ -28,9 +28,8 @@ because connections are instantiated lazily.
 
 ## Troubleshooting connection-pool issues
 
-The connection-pool usage can be seen per environment in the [connection-pool
-saturation
-dashboard](https://dashboards.gitlab.net/d/alerts-sat_rails_db_connection_pool/alerts-rails_db_connection_pool-saturation-detail?orgId=1).
+The connection-pool usage can be seen per environment in the 
+[connection-pool saturation dashboard](https://dashboards.gitlab.net/d/alerts-sat_rails_db_connection_pool/alerts-rails_db_connection_pool-saturation-detail?orgId=1).
 
 If the connection-pool is too small, this would manifest in
 `ActiveRecord::ConnectionTimeoutError`s from the application. Because we alert
@@ -41,8 +40,8 @@ hardcoded value (10).
 
 At this point, we need to investigate what is using more connections
 than we anticipated. To do that, we can use the
-`gitlab_ruby_threads_running_threads` metric. For example, [this
-graph](https://thanos.gitlab.net/graph?g0.range_input=1h&g0.max_source_resolution=0s&g0.expr=sum%20by%20(thread_name)%20(%20gitlab_ruby_threads_running_threads%7Buses_db_connection%3D%22yes%22%7D%20)&g0.tab=0)
+`gitlab_ruby_threads_running_threads` metric. For example,
+[this graph](https://thanos.gitlab.net/graph?g0.range_input=1h&g0.max_source_resolution=0s&g0.expr=sum%20by%20(thread_name)%20(%20gitlab_ruby_threads_running_threads%7Buses_db_connection%3D%22yes%22%7D%20)&g0.tab=0)
 shows all running threads that connect to the database by their
 name. Threads labeled `puma worker` or `sidekiq_worker_thread` are
 the threads that define `Gitlab::Runtime.max_threads` so those are
diff --git a/doc/development/database/loose_foreign_keys.md b/doc/development/database/loose_foreign_keys.md
index e28237ca5fc..8dbccf048d7 100644
--- a/doc/development/database/loose_foreign_keys.md
+++ b/doc/development/database/loose_foreign_keys.md
@@ -221,8 +221,8 @@ ON DELETE CASCADE;
 ```
 
 The migration must run after the `DELETE` trigger is installed and the loose
-foreign key definition is deployed. As such, it must be a [post-deployment
-migration](post_deployment_migrations.md) dated after the migration for the
+foreign key definition is deployed. As such, it must be a 
+[post-deployment migration](post_deployment_migrations.md) dated after the migration for the
 trigger. If the foreign key is deleted earlier, there is a good chance of
 introducing data inconsistency which needs manual cleanup:
 
diff --git a/doc/development/database/rename_database_tables.md b/doc/development/database/rename_database_tables.md
index cbcbd507204..4a3b9df0c33 100644
--- a/doc/development/database/rename_database_tables.md
+++ b/doc/development/database/rename_database_tables.md
@@ -81,8 +81,8 @@ Execute a standard migration (not a post-migration):
 when naming indexes, so there is a possibility that not all indexes are properly renamed. After running
 the migration locally, check if there are inconsistently named indexes (`db/structure.sql`). Those can be
 renamed manually in a separate migration, which can be also part of the release M.N+1.
-- Foreign key columns might still contain the old table name. For smaller tables, follow our [standard column
-rename process](avoiding_downtime_in_migrations.md#renaming-columns)
+- Foreign key columns might still contain the old table name. For smaller tables, follow our
+  [standard column rename process](avoiding_downtime_in_migrations.md#renaming-columns)
 - Avoid renaming database tables which are using with triggers.
 - Table modifications (add or remove columns) are not allowed during the rename process, please make sure that all changes to the table happen before the rename migration is started (or in the next release).
 - As the index names might change, verify that the model does not use bulk insert
diff --git a/doc/development/database/strings_and_the_text_data_type.md b/doc/development/database/strings_and_the_text_data_type.md
index 73e023f8d45..ee74e57ed32 100644
--- a/doc/development/database/strings_and_the_text_data_type.md
+++ b/doc/development/database/strings_and_the_text_data_type.md
@@ -148,8 +148,9 @@ to update the `title_html` with a title that has more than 1024 characters, the
 a database error.
 
 Adding or removing a constraint to an existing attribute requires that any application changes are
-deployed _first_, [otherwise servers still in the old version of the application may try to update the
-attribute with invalid values](../multi_version_compatibility.md#ci-artifact-uploads-were-failing).
+deployed _first_, 
+otherwise servers still in the old version of the application
+[may try to update the attribute with invalid values](../multi_version_compatibility.md#ci-artifact-uploads-were-failing).
 For these reasons, `add_text_limit` should run in a post-deployment migration.
 
 Still in our example, for the 13.0 milestone (current), consider that the following validation
diff --git a/doc/development/database/understanding_explain_plans.md b/doc/development/database/understanding_explain_plans.md
index 49babde737a..446a84d5232 100644
--- a/doc/development/database/understanding_explain_plans.md
+++ b/doc/development/database/understanding_explain_plans.md
@@ -252,8 +252,8 @@ A scan on an index that required retrieving some data from the table.
 
 Bitmap scans fall between sequential scans and index scans. These are typically
 used when we would read too much data from an index scan, but too little to
-perform a sequential scan. A bitmap scan uses what is known as a [bitmap
-index](https://en.wikipedia.org/wiki/Bitmap_index) to perform its work.
+perform a sequential scan. A bitmap scan uses what is known as a 
+[bitmap index](https://en.wikipedia.org/wiki/Bitmap_index) to perform its work.
 
 The [source code of PostgreSQL](https://gitlab.com/postgres/postgres/blob/REL_11_STABLE/src/include/nodes/plannodes.h#L441)
 states the following on bitmap scans:
@@ -794,8 +794,8 @@ Execution time: 0.113 ms
 
 ### ChatOps
 
-[GitLab team members can also use our ChatOps solution, available in Slack using the
-`/chatops` slash command](../chatops_on_gitlabcom.md).
+GitLab team members can also use our ChatOps solution, available in Slack
+using the [`/chatops` slash command](../chatops_on_gitlabcom.md).
 
 NOTE:
 While ChatOps is still available, the recommended way to generate execution plans is to use [Database Lab Engine](#database-lab-engine).
diff --git a/doc/development/internal_api/index.md b/doc/development/internal_api/index.md
index 327e750145c..c3703417f39 100644
--- a/doc/development/internal_api/index.md
+++ b/doc/development/internal_api/index.md
@@ -148,8 +148,8 @@ curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded token>" \
 ## Authorized Keys Check
 
 This endpoint is called by the GitLab Shell authorized keys
-check. Which is called by OpenSSH for [fast SSH key
-lookup](../../administration/operations/fast_ssh_key_lookup.md).
+check. Which is called by OpenSSH for 
+[fast SSH key lookup](../../administration/operations/fast_ssh_key_lookup.md).
 
 | Attribute | Type   | Required | Description |
 |:----------|:-------|:---------|:------------|
diff --git a/doc/development/issue_types.md b/doc/development/issue_types.md
index e6047c62827..820c37aeb14 100644
--- a/doc/development/issue_types.md
+++ b/doc/development/issue_types.md
@@ -13,10 +13,8 @@ Sometimes when a new resource type is added it's not clear if it should be only
 "extension" of Issue (Issue Type) or if it should be a new first-class resource type
 (similar to issue, epic, merge request, snippet).
 
-The idea of Issue Types was first proposed in [this
-issue](https://gitlab.com/gitlab-org/gitlab/-/issues/8767) and its usage was
-discussed few times since then, for example in [incident
-management](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/55532).
+The idea of Issue Types was first proposed in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/8767) and its usage was
+discussed few times since then, for example in [incident management](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/55532).
 
 ## What is an Issue Type
 
diff --git a/doc/development/lfs.md b/doc/development/lfs.md
index 9b78c8869b1..5900eb68294 100644
--- a/doc/development/lfs.md
+++ b/doc/development/lfs.md
@@ -76,14 +76,13 @@ process, which writes the contents to the standard output.
 1. The archive data is sent back to the client.
 
 In step 7, the `gitaly-lfs-smudge` filter must talk to Workhorse, not to
-Rails, or an invalid LFS blob is saved. To support this, GitLab
-13.5 [changed the default Omnibus configuration to have Gitaly talk to
-the Workhorse](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4592)
+Rails, or an invalid LFS blob is saved. To support this, GitLab 13.5 
+[changed the default Omnibus configuration to have Gitaly talk to the Workhorse](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4592)
 instead of Rails.
 
 One side effect of this change: the correlation ID of the original
 request is not preserved for the internal API requests made by Gitaly
 (or `gitaly-lfs-smudge`), such as the one made in step 8. The
-correlation IDs for those API requests are random values until [this
-Workhorse issue](https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/309) is
+correlation IDs for those API requests are random values until 
+[this Workhorse issue](https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/309) is
 resolved.
diff --git a/doc/development/real_time.md b/doc/development/real_time.md
index df725a36a93..21f3ee1f3b2 100644
--- a/doc/development/real_time.md
+++ b/doc/development/real_time.md
@@ -60,8 +60,8 @@ downstream services.
 
 To mitigate this, ensure that the code establishing the new WebSocket connection
 is feature flagged and defaulted to `off`. A careful, percentage-based roll-out
-of the feature flag ensures that effects can be observed on the [WebSocket
-dashboard](https://dashboards.gitlab.net/d/websockets-main/websockets-overview?orgId=1)
+of the feature flag ensures that effects can be observed on the 
+[WebSocket dashboard](https://dashboards.gitlab.net/d/websockets-main/websockets-overview?orgId=1)
 
 1. Create a
    [feature flag roll-out](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20Flag%20Roll%20Out.md)
diff --git a/doc/development/service_ping/index.md b/doc/development/service_ping/index.md
index 821f44f0d8a..4481fe33bda 100644
--- a/doc/development/service_ping/index.md
+++ b/doc/development/service_ping/index.md
@@ -111,7 +111,7 @@ sequenceDiagram
 
 1. Finally, the timing metadata information that is used for diagnostic purposes is submitted to the Versions application. It consists of a list of metric identifiers and the time it took to calculate the metrics:
 
-   > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37911) in GitLab 15.0 [with a flag(../../user/feature_flags.md), enabled by default.
+   > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37911) in GitLab 15.0 [with a flag](../../user/feature_flags.md), enabled by default.
    > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/295289) in GitLab 15.2. [Feature flag `measure_service_ping_metric_collection`](https://gitlab.com/gitlab-org/gitlab/-/issues/358128) removed.
 
 ```ruby
diff --git a/doc/development/sql.md b/doc/development/sql.md
index 8553e2a5500..7101bf7fb4b 100644
--- a/doc/development/sql.md
+++ b/doc/development/sql.md
@@ -79,8 +79,9 @@ ON table_name
 USING GIN(column_name gin_trgm_ops);
 ```
 
-The key here is the `GIN(column_name gin_trgm_ops)` part. This creates a [GIN
-index](https://www.postgresql.org/docs/current/gin.html) with the operator class set to `gin_trgm_ops`. These indexes
+The key here is the `GIN(column_name gin_trgm_ops)` part. This creates a
+[GIN index](https://www.postgresql.org/docs/current/gin.html) 
+with the operator class set to `gin_trgm_ops`. These indexes
 _can_ be used by `ILIKE` / `LIKE` and can lead to greatly improved performance.
 One downside of these indexes is that they can easily get quite large (depending
 on the amount of data indexed).
diff --git a/doc/development/workhorse/index.md b/doc/development/workhorse/index.md
index de3636fa112..962124248ef 100644
--- a/doc/development/workhorse/index.md
+++ b/doc/development/workhorse/index.md
@@ -10,8 +10,8 @@ GitLab Workhorse is a smart reverse proxy for GitLab. It handles
 "large" HTTP requests such as file downloads, file uploads, Git
 push/pull and Git archive downloads.
 
-Workhorse itself is not a feature, but there are [several features in
-GitLab](gitlab_features.md) that would not work efficiently without Workhorse.
+Workhorse itself is not a feature, but there are 
+[several features in GitLab](gitlab_features.md) that would not work efficiently without Workhorse.
 
 The canonical source for Workhorse is
 [`gitlab-org/gitlab/workhorse`](https://gitlab.com/gitlab-org/gitlab/tree/master/workhorse).