Add latest changes from gitlab-org/gitlab@master

35 files changed, 158 insertions, 182 deletions

diff --git a/doc/api/container_registry.md b/doc/api/container_registry.md
index eef90fc512e..9ad52fa3c3a 100644
--- a/doc/api/container_registry.md
+++ b/doc/api/container_registry.md
@@ -33,13 +33,11 @@ PUT /projects/:id/
 Descriptions of the possible values for `container_registry_access_level`:
 
 - **enabled** (Default): The container registry is visible to everyone with access to the project.
-If the project is public, the container registry is also public. If the project is internal or
-private, the container registry is also internal or private.
-
+  If the project is public, the container registry is also public. If the project is internal or
+  private, the container registry is also internal or private.
 - **private**: The container registry is visible only to project members with Reporter role or
-higher. This behavior is similar to that of a private project with container registry visibility set
-to **enabled**.
-
+  higher. This behavior is similar to that of a private project with container registry visibility set
+  to **enabled**.
 - **disabled**: The container registry is disabled.
 
 See the [container registry visibility permissions](../user/packages/container_registry/index.md#container-registry-visibility-permissions)
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index aaa1a7c559b..6669ed071e0 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -5383,22 +5383,12 @@ Input type: `MemberRoleCreateInput`
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="mutationmemberrolecreateadmingroupmember"></a>`adminGroupMember` | [`Boolean`](#boolean) | Permission to admin group members. |
-| <a id="mutationmemberrolecreateadminmergerequest"></a>`adminMergeRequest` | [`Boolean`](#boolean) | Permission to admin merge requests. |
-| <a id="mutationmemberrolecreateadminvulnerability"></a>`adminVulnerability` | [`Boolean`](#boolean) | Permission to admin vulnerability. |
-| <a id="mutationmemberrolecreatearchiveproject"></a>`archiveProject` | [`Boolean`](#boolean) | Permission to archive projects. |
 | <a id="mutationmemberrolecreatebaseaccesslevel"></a>`baseAccessLevel` | [`MemberAccessLevel!`](#memberaccesslevel) | Base access level for the custom role. |
 | <a id="mutationmemberrolecreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
 | <a id="mutationmemberrolecreatedescription"></a>`description` | [`String`](#string) | Description of the member role. |
 | <a id="mutationmemberrolecreategrouppath"></a>`groupPath` | [`ID`](#id) | Group the member role to mutate is in. Required for SaaS. |
-| <a id="mutationmemberrolecreatemanagegroupaccesstokens"></a>`manageGroupAccessTokens` | [`Boolean`](#boolean) | Permission to admin group access tokens. |
-| <a id="mutationmemberrolecreatemanageprojectaccesstokens"></a>`manageProjectAccessTokens` | [`Boolean`](#boolean) | Permission to admin project access tokens. |
 | <a id="mutationmemberrolecreatename"></a>`name` | [`String`](#string) | Name of the member role. |
 | <a id="mutationmemberrolecreatepermissions"></a>`permissions` | [`[MemberRolePermission!]`](#memberrolepermission) | List of all customizable permissions. |
-| <a id="mutationmemberrolecreatereadcode"></a>`readCode` | [`Boolean`](#boolean) | Permission to read code. |
-| <a id="mutationmemberrolecreatereaddependency"></a>`readDependency` | [`Boolean`](#boolean) | Permission to read dependency. |
-| <a id="mutationmemberrolecreatereadvulnerability"></a>`readVulnerability` | [`Boolean`](#boolean) | Permission to read vulnerability. |
-| <a id="mutationmemberrolecreateremoveproject"></a>`removeProject` | [`Boolean`](#boolean) | Permission to delete projects. |
 
 #### Fields
 
@@ -21485,22 +21475,12 @@ Represents a member role.
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="memberroleadmingroupmember"></a>`adminGroupMember` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.5. This feature is an Experiment. It can be changed or removed at any time. Permission to admin group members. |
-| <a id="memberroleadminmergerequest"></a>`adminMergeRequest` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.5. This feature is an Experiment. It can be changed or removed at any time. Permission to admin merge requests. |
-| <a id="memberroleadminvulnerability"></a>`adminVulnerability` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.5. This feature is an Experiment. It can be changed or removed at any time. Permission to admin vulnerability. |
-| <a id="memberrolearchiveproject"></a>`archiveProject` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.6. This feature is an Experiment. It can be changed or removed at any time. Permission to archive projects. |
 | <a id="memberrolebaseaccesslevel"></a>`baseAccessLevel` **{warning-solid}** | [`AccessLevel!`](#accesslevel) | **Introduced** in 16.5. This feature is an Experiment. It can be changed or removed at any time. Base access level for the custom role. |
 | <a id="memberroledescription"></a>`description` | [`String`](#string) | Description of the member role. |
 | <a id="memberroleenabledpermissions"></a>`enabledPermissions` **{warning-solid}** | [`[MemberRolePermission!]`](#memberrolepermission) | **Introduced** in 16.5. This feature is an Experiment. It can be changed or removed at any time. Array of all permissions enabled for the custom role. |
 | <a id="memberroleid"></a>`id` | [`MemberRoleID!`](#memberroleid) | ID of the member role. |
-| <a id="memberrolemanagegroupaccesstokens"></a>`manageGroupAccessTokens` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.8. This feature is an Experiment. It can be changed or removed at any time. Permission to admin group access tokens. |
-| <a id="memberrolemanageprojectaccesstokens"></a>`manageProjectAccessTokens` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.5. This feature is an Experiment. It can be changed or removed at any time. Permission to admin project access tokens. |
 | <a id="memberrolememberscount"></a>`membersCount` **{warning-solid}** | [`Int!`](#int) | **Introduced** in 16.7. This feature is an Experiment. It can be changed or removed at any time. Total number of members with the custom role. |
 | <a id="memberrolename"></a>`name` | [`String!`](#string) | Name of the member role. |
-| <a id="memberrolereadcode"></a>`readCode` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.5. This feature is an Experiment. It can be changed or removed at any time. Permission to read code. |
-| <a id="memberrolereaddependency"></a>`readDependency` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.5. This feature is an Experiment. It can be changed or removed at any time. Permission to read dependency. |
-| <a id="memberrolereadvulnerability"></a>`readVulnerability` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.5. This feature is an Experiment. It can be changed or removed at any time. Permission to read vulnerability. |
-| <a id="memberroleremoveproject"></a>`removeProject` **{warning-solid}** | [`Boolean`](#boolean) | **Introduced** in 16.8. This feature is an Experiment. It can be changed or removed at any time. Permission to delete projects. |
 
 ### `MergeAccessLevel`
 
diff --git a/doc/ci/runners/saas/macos_saas_runner.md b/doc/ci/runners/saas/macos_saas_runner.md
index 03c23680c1c..0251c523864 100644
--- a/doc/ci/runners/saas/macos_saas_runner.md
+++ b/doc/ci/runners/saas/macos_saas_runner.md
@@ -21,8 +21,7 @@ You can follow our work towards this goal in the
 
 ## Machine types available for macOS
 
-GitLab SaaS provides macOS build machines on Apple silicon (M1) chips.
-Intel x86-64 runners were deprecated in favor of Apple silicon. To build for an x86-64 target, use Rosetta 2 to emulate an Intel x86-64 build environment.
+GitLab SaaS provides macOS build machines on Apple silicon (M1) chips. To build for an x86-64 target, you can use Rosetta 2 to emulate an Intel x86-64 build environment.
 
 | Runner Tag             | vCPUS | Memory | Storage |
 | ---------------------- | ----- | ------ | ------- |
@@ -40,7 +39,7 @@ in your `.gitlab-ci.yml` file. Each image runs a specific version of macOS and X
 |----------------------------|--------|--------------|
 | `macos-12-xcode-14`        | `GA`   |              |
 | `macos-13-xcode-14`        | `GA`   | [Preinstalled Software](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/job-images/-/blob/main/toolchain/macos-13.yml) |
-| `macos-14-xcode-15`        | `Beta` | [Preinstalled Software](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/job-images/-/blob/main/toolchain/macos-14.yml) |
+| `macos-14-xcode-15`        | `GA`   | [Preinstalled Software](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/job-images/-/blob/main/toolchain/macos-14.yml) |
 
 If no image is specified, the macOS runner uses `macos-13-xcode-14`.
 
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md
index 0e922550856..a0888006937 100644
--- a/doc/development/contributing/design.md
+++ b/doc/development/contributing/design.md
@@ -41,10 +41,10 @@ Check these aspects both when _designing_ and _reviewing_ UI changes.
 
 ### Writing
 
-- Follow [Pajamas](https://design.gitlab.com/content/punctuation/) as the primary
+- Follow [Pajamas](https://design.gitlab.com/content/ui-text/) as the primary
   guidelines for UI text and [documentation style guide](../documentation/styleguide/index.md)
   as the secondary.
-- Use clear and consistent [terminology](https://design.gitlab.com/content/terminology/).
+- Use clear and consistent terminology.
 - Check grammar and spelling.
 - Consider help content and follow its [guidelines](https://design.gitlab.com/usability/contextual-help).
 - Request review from the [appropriate Technical Writer](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments),
diff --git a/doc/development/database/avoiding_downtime_in_migrations.md b/doc/development/database/avoiding_downtime_in_migrations.md
index bf75b7c2ab2..57c71cbaec6 100644
--- a/doc/development/database/avoiding_downtime_in_migrations.md
+++ b/doc/development/database/avoiding_downtime_in_migrations.md
@@ -588,27 +588,27 @@ swap the columns. Swapping is done with post-deployment migration. The exact pro
 table being converted, but in general it's done in the following steps:
 
 1. Using the provided `ensure_batched_background_migration_is_finished` helper, make sure the batched
-migration has finished ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L13-18)).
-If the migration has not completed, the subsequent steps fail anyway. By checking in advance we
-aim to have more helpful error message.
+   migration has finished ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L13-18)).
+   If the migration has not completed, the subsequent steps fail anyway. By checking in advance we
+   aim to have more helpful error message.
 1. Use the `add_bigint_column_indexes` helper method from `Gitlab::Database::MigrationHelpers::ConvertToBigint` module
    to create indexes with the `bigint` columns that match the existing indexes using the `integer` column.
    - The helper method is expected to create all required `bigint` indexes, but it's advised to recheck to make sure
      we are not missing any of the existing indexes. More information about the helper can be
      found in merge request [135781](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/135781).
 1. Create foreign keys (FK) using the `bigint` columns that match the existing FK using the
-`integer` column. Do this both for FK referencing other tables, and FK that reference the table
-that is being migrated ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L36-43)).
+   `integer` column. Do this both for FK referencing other tables, and FK that reference the table
+   that is being migrated ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L36-43)).
 1. Inside a transaction, swap the columns:
-    1. Lock the tables involved. To reduce the chance of hitting a deadlock, we recommended to do this in parent to child order ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L47)).
-    1. Rename the columns to swap names ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L49-54))
-    1. Reset the trigger function ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L56-57)).
-    1. Swap the defaults ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L59-62)).
-    1. Swap the PK constraint (if any) ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L64-68)).
-    1. Remove old indexes and rename new ones ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L70-72)).
-       - Names of the `bigint` indexes created using `add_bigint_column_indexes` helper can be retrieved by calling
-         `bigint_index_name` from `Gitlab::Database::MigrationHelpers::ConvertToBigint` module.
-    1. Remove old foreign keys (if still present) and rename new ones ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L74)).
+   1. Lock the tables involved. To reduce the chance of hitting a deadlock, we recommended to do this in parent to child order ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L47)).
+   1. Rename the columns to swap names ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L49-54))
+   1. Reset the trigger function ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L56-57)).
+   1. Swap the defaults ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L59-62)).
+   1. Swap the PK constraint (if any) ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L64-68)).
+   1. Remove old indexes and rename new ones ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L70-72)).
+      - Names of the `bigint` indexes created using `add_bigint_column_indexes` helper can be retrieved by calling
+        `bigint_index_name` from `Gitlab::Database::MigrationHelpers::ConvertToBigint` module.
+   1. Remove old foreign keys (if still present) and rename new ones ([see an example](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb#L74)).
 
 See example [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66088), and [migration](https://gitlab.com/gitlab-org/gitlab/-/blob/41fbe34a4725a4e357a83fda66afb382828767b2/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb).
 
diff --git a/doc/development/database/efficient_in_operator_queries.md b/doc/development/database/efficient_in_operator_queries.md
index 8e334e5bb5c..e1a7b56e35e 100644
--- a/doc/development/database/efficient_in_operator_queries.md
+++ b/doc/development/database/efficient_in_operator_queries.md
@@ -916,16 +916,16 @@ Here's an outline of the steps we take in the recursive CTE query
 
 1. Sort the initial `resultset` according to the `ORDER BY` clause.
 1. Pick the top cursor to fetch the record, this is our first record. In the example,
-this cursor would be (`2020-01-05`, `3`) for `project_id=9`.
+   this cursor would be (`2020-01-05`, `3`) for `project_id=9`.
 1. We can use (`2020-01-05`, `3`) to fetch the next issue respecting the `ORDER BY` clause
-`project_id=9` filter. This produces an updated `resultset`.
+   `project_id=9` filter. This produces an updated `resultset`.
 
-  | `project_ids` | `created_at_values` | `id_values` |
-  | ------------- | ------------------- | ----------- |
-  | 2             | 2020-01-10          | 5           |
-  | 5             | 2020-01-05          | 4           |
-  | 10            | 2020-01-15          | 7           |
-  | **9**         | **2020-01-06**      | **6**       |
+   | `project_ids` | `created_at_values` | `id_values` |
+   | ------------- | ------------------- | ----------- |
+   | 2             | 2020-01-10          | 5           |
+   | 5             | 2020-01-05          | 4           |
+   | 10            | 2020-01-15          | 7           |
+   | **9**         | **2020-01-06**      | **6**       |
 
 1. Repeat 1 to 3 with the updated `resultset` until we have fetched `N=20` records.
 
@@ -944,9 +944,9 @@ Example initializer row:
 | `NULL::issues` | `[9, 2, 5, 10]` | `[...]`             | `[...]`     | `0`     | `NULL`     |
 
 - The `records` column contains our sorted database records, and the initializer query sets the
-first value to `NULL`, which is filtered out later.
+  first value to `NULL`, which is filtered out later.
 - The `count` column tracks the number of records found. We use this column to filter out the
-initializer row from the result set.
+  initializer row from the result set.
 
 ### Recursive portion of the CTE query
 
@@ -1016,7 +1016,7 @@ As the final step, we need to produce a new row by manipulating the initializer
 (`data_collector_query` method). Two things happen here:
 
 - Read the full row from the DB and return it in the `records` columns. (`result_collector_columns`
-method)
+  method)
 - Replace the cursor values at the current position with the results from the keyset query.
 
 Reading the full row from the database is only one index scan by the primary key. We use the
@@ -1091,7 +1091,7 @@ in the PostgreSQL's buffer cache.
 The optimized `IN` query reads maximum 519 entries (cursor values) from the index:
 
 - 500 index-only scans for populating the arrays for each project. The cursor values of the first
-record is here.
+  record is here.
 - Maximum 19 additional index-only scans for the consecutive records.
 
 The optimized `IN` query sorts the array (cursor values per project array) 20 times, which
diff --git a/doc/development/database/iterating_tables_in_batches.md b/doc/development/database/iterating_tables_in_batches.md
index 802b7622592..7192a84508e 100644
--- a/doc/development/database/iterating_tables_in_batches.md
+++ b/doc/development/database/iterating_tables_in_batches.md
@@ -414,12 +414,12 @@ the queries, where the `issues` table is batched first.
 When to use `JOINS`:
 
 - When there's a 1:1 or 1:N relationship between the tables where we know that the joined record
-(almost) always exists. This works well for "extension-like" tables:
+  (almost) always exists. This works well for "extension-like" tables:
   - `projects` - `project_settings`
   - `users` - `user_details`
   - `users` - `user_statuses`
 - `LEFT JOIN` works well in this case. Conditions on the joined table need to go to the yielded
-relation so the iteration is not affected by the data distribution in the joined table.
+  relation so the iteration is not affected by the data distribution in the joined table.
 
 Example:
 
@@ -555,7 +555,7 @@ table or a range of rows. The scaling and performance characteristics are very s
 Examples:
 
 - Iterate over the table in a specific order (timestamp columns) in combination with a tie-breaker
-if column user to sort by does not contain unique values.
+  if column user to sort by does not contain unique values.
 - Iterate over the table with composite primary keys.
 
 ### Iterate over the issues in a project by creation date
@@ -619,8 +619,8 @@ To keep the iteration stable and predictable, avoid updating the columns in the
 
 ### Iterate over the `merge_request_diff_commits` table
 
-The `merge_request_diff_commits` table uses a composite primary key (`merge_request_diff_id,
-relative_order`), which makes `EachBatch` impossible to use efficiently.
+The `merge_request_diff_commits` table uses a composite primary key (`merge_request_diff_id, relative_order`),
+which makes `EachBatch` impossible to use efficiently.
 
 To paginate over the `merge_request_diff_commits` table, you can use the following snippet:
 
@@ -654,7 +654,7 @@ end
 ### Order object configuration
 
 Keyset pagination works well with simple `ActiveRecord` `order` scopes
-([first example](#iterate-over-the-issues-in-a-project-by-creation-date).
+([first example](#iterate-over-the-issues-in-a-project-by-creation-date)).
 However, in special cases, you need to describe the columns in the `ORDER BY` clause (second example)
 for the underlying keyset pagination library. When the `ORDER BY` configuration cannot be
 automatically determined by the keyset pagination library, an error is raised.
diff --git a/doc/development/database/loose_foreign_keys.md b/doc/development/database/loose_foreign_keys.md
index 3003ee970ce..9ecc70c06bc 100644
--- a/doc/development/database/loose_foreign_keys.md
+++ b/doc/development/database/loose_foreign_keys.md
@@ -499,7 +499,7 @@ cron job where the schedule depends on the configuration of the GitLab instance.
 
 - Non-decomposed GitLab (1 database): invoked every minute.
 - Decomposed GitLab (2 databases, CI and Main): invoked every minute, cleaning up one database
-at a time. For example, the cleanup worker for the main database runs every two minutes.
+  at a time. For example, the cleanup worker for the main database runs every two minutes.
 
 To avoid lock contention and the processing of the same database rows, the worker does not run
 parallel. This behavior is ensured with a Redis lock.
@@ -509,13 +509,13 @@ parallel. This behavior is ensured with a Redis lock.
 1. Acquire the Redis lock.
 1. Determine which database to clean up.
 1. Collect all database tables where the deletions are tracked (parent tables).
-    - This is achieved by reading the `config/gitlab_loose_foreign_keys.yml` file.
-    - A table is considered "tracked" when a loose foreign key definition exists for the table and
-    the `DELETE` trigger is installed.
+   - This is achieved by reading the `config/gitlab_loose_foreign_keys.yml` file.
+   - A table is considered "tracked" when a loose foreign key definition exists for the table and
+     the `DELETE` trigger is installed.
 1. Cycle through the tables with an infinite loop.
 1. For each table, load a batch of deleted parent records to clean up.
 1. Depending on the YAML configuration, build `DELETE` or `UPDATE` (nullify) queries for the
-referenced child tables.
+   referenced child tables.
 1. Invoke the queries.
 1. Repeat until all child records are cleaned up or the maximum limit is reached.
 1. Remove the deleted parent records when all child records are cleaned up.
@@ -530,13 +530,13 @@ The inserted record stores the following information about the deleted record:
 
 - `fully_qualified_table_name`: name of the database table where the record was located.
 - `primary_key_value`: the ID of the record, the value is present in the child tables as
-the foreign key value. At the moment, composite primary keys are not supported, the parent table
-must have an `id` column.
+  the foreign key value. At the moment, composite primary keys are not supported, the parent table
+  must have an `id` column.
 - `status`: defaults to pending, represents the status of the cleanup process.
 - `consume_after`: defaults to the current time.
 - `cleanup_attempts`: defaults to 0. The number of times the worker tried to clean up this record.
-A non-zero number would mean that this record has many child records and cleaning it up requires
-several runs.
+  A non-zero number would mean that this record has many child records and cleaning it up requires
+  several runs.
 
 #### Database decomposition
 
@@ -692,7 +692,7 @@ The loop-based batch processing is preferred over `EachBatch` for the following
 
 - The records in the batch are modified, so the next batch contains different records.
 - There is always an index on the foreign key column however, the column is usually not unique.
-`EachBatch` requires a unique column for the iteration.
+  `EachBatch` requires a unique column for the iteration.
 - The record order doesn't matter for the cleanup.
 
 Notice that we have two loops. The initial loop processes records with the `SKIP LOCKED` clause.
@@ -747,23 +747,23 @@ For example, a project with millions of `ci_builds` records is deleted. The `ci_
 is deleted by the loose foreign keys feature.
 
 1. The cleanup worker is scheduled and picks up a batch of deleted `projects` records. The large
-project is part of the batch.
+   project is part of the batch.
 1. Deletion of the orphaned `ci_builds` rows has started.
 1. The time limit is reached, but the cleanup is not complete.
 1. The `cleanup_attempts` column is incremented for the deleted records.
 1. Go to step 1. The next cleanup worker continues the cleanup.
 1. When the `cleanup_attempts` reaches 3, the batch is re-scheduled 10 minutes later by updating
-the `consume_after` column.
+   the `consume_after` column.
 1. The next cleanup worker processes a different batch.
 
 We have Prometheus metrics in place to monitor the deleted record cleanup:
 
 - `loose_foreign_key_processed_deleted_records`: Number of processed deleted records. When large
-cleanup happens, this number would decrease.
+  cleanup happens, this number would decrease.
 - `loose_foreign_key_incremented_deleted_records`: Number of deleted records which were not
-finished processing. The `cleanup_attempts` column was incremented.
+  finished processing. The `cleanup_attempts` column was incremented.
 - `loose_foreign_key_rescheduled_deleted_records`: Number of deleted records that had to be
-rescheduled at a later time after 3 cleanup attempts.
+  rescheduled at a later time after 3 cleanup attempts.
 
 Example Thanos query:
 
diff --git a/doc/development/database/maintenance_operations.md b/doc/development/database/maintenance_operations.md
index 2701c228b74..fcdf132aa09 100644
--- a/doc/development/database/maintenance_operations.md
+++ b/doc/development/database/maintenance_operations.md
@@ -18,7 +18,7 @@ There are certain situations in which you might want to disable an index before
 To disable an index before removing it:
 
 1. Open a [production infrastructure issue](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/new)
-and use the "Production Change" template.
+   and use the "Production Change" template.
 1. Inform the database team in the issue `@gl-database` or in Slack `#database`.
 1. Add a step to verify the index is used (this would likely be an `EXPLAIN` command known to use the index).
 1. Add the step to disable the index:
diff --git a/doc/development/database/rename_database_tables.md b/doc/development/database/rename_database_tables.md
index ad641797496..babd51f91a0 100644
--- a/doc/development/database/rename_database_tables.md
+++ b/doc/development/database/rename_database_tables.md
@@ -78,18 +78,18 @@ Execute a standard migration (not a post-migration):
   - Add a note in the Engineering Week-in-Review document: `table_name` is going to be renamed in N.M. Modifications to this table are not allowed in release N.M and N.M+1.
 - The helper method uses the standard `rename_table` helper from Rails for renaming the table.
 - The helper renames the sequence and the indexes. Sometimes it diverges from the standard Rails convention
-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.
+  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)
 - Avoid renaming database tables which are using with triggers.
 - Table modifications (add or remove columns) are not allowed during the rename process. 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
-(for example, `insert_all` and `upsert_all`) with the `unique_by: index_name` option.
-Renaming an index while using these methods may break functionality.
+  (for example, `insert_all` and `upsert_all`) with the `unique_by: index_name` option.
+  Renaming an index while using these methods may break functionality.
 - Modify the model code to point to the new database table. Do this by
-renaming the model directly or setting the `self.table_name` variable.
+  renaming the model directly or setting the `self.table_name` variable.
 
 At this point, we don't have applications using the old database table name in their queries.
 
@@ -107,7 +107,7 @@ At this point, we don't have applications using the old database table name in t
 
 1. Additionally the table definition from `TABLES_TO_BE_RENAMED` **must** be removed.
 
-To do so, edit the `TABLES_TO_BE_RENAMED` constant in `lib/gitlab/database.rb`:
+   To do so, edit the `TABLES_TO_BE_RENAMED` constant in `lib/gitlab/database.rb`:
 
    From:
 
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 70d59603e0c..50188dba14e 100644
--- a/doc/development/database/strings_and_the_text_data_type.md
+++ b/doc/development/database/strings_and_the_text_data_type.md
@@ -12,8 +12,8 @@ When adding new columns to store strings or other textual information:
 
 1. We always use the `text` data type instead of the `string` data type.
 1. `text` columns should always have a limit set, either by using the `create_table` with
-the `#text ... limit: 100` helper (see below) when creating a table, or by using the `add_text_limit`
-when altering an existing table.
+   the `#text ... limit: 100` helper (see below) when creating a table, or by using the `add_text_limit`
+   when altering an existing table.
 
 The standard Rails `text` column type cannot be defined with a limit, but we extend `create_table` to
 add a `limit: 255` option. Outside of `create_table`, `add_text_limit` can be used to add a [check constraint](https://www.postgresql.org/docs/11/ddl-constraints.html)
diff --git a/doc/development/database/table_partitioning.md b/doc/development/database/table_partitioning.md
index 4d3101b40fb..2b805e964c7 100644
--- a/doc/development/database/table_partitioning.md
+++ b/doc/development/database/table_partitioning.md
@@ -19,15 +19,15 @@ table. If the application is designed to work with partitioning in mind,
 there can be multiple benefits, such as:
 
 - Query performance can be improved greatly, because the database can
-cheaply eliminate much of the data from the search space, while still
-providing full SQL capabilities.
+  cheaply eliminate much of the data from the search space, while still
+  providing full SQL capabilities.
 
 - Bulk deletes can be achieved with minimal impact on the database by
-dropping entire partitions. This is a natural fit for features that need
-to periodically delete data that falls outside the retention window.
+  dropping entire partitions. This is a natural fit for features that need
+  to periodically delete data that falls outside the retention window.
 
 - Administrative tasks like `VACUUM` and index rebuilds can operate on
-individual partitions, rather than across a single massive table.
+  individual partitions, rather than across a single massive table.
 
 Unfortunately, not all models fit a partitioning scheme, and there are
 significant drawbacks if implemented incorrectly. Additionally, tables
diff --git a/doc/development/fe_guide/content_editor.md b/doc/development/fe_guide/content_editor.md
index 7a76b39edbc..64cf7de75ab 100644
--- a/doc/development/fe_guide/content_editor.md
+++ b/doc/development/fe_guide/content_editor.md
@@ -46,7 +46,7 @@ export default {
 The rich text editor requires two properties:
 
 - `renderMarkdown` is an asynchronous function that returns the response (String) of invoking the
-[Markdown API](../../api/markdown.md).
+  [Markdown API](../../api/markdown.md).
 - `uploadsPath` is a URL that points to a [GitLab upload service](../uploads/index.md)
   with `multipart/form-data` support.
 
diff --git a/doc/development/fe_guide/customizable_dashboards.md b/doc/development/fe_guide/customizable_dashboards.md
index 93b5b20b047..9ba0d4bb40c 100644
--- a/doc/development/fe_guide/customizable_dashboards.md
+++ b/doc/development/fe_guide/customizable_dashboards.md
@@ -98,7 +98,7 @@ export const pageViewsOverTime = {
 To add a new visualization render type:
 
 1. Create a new Vue component that accepts `data` and `options` properties.
-See [`line_chart.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/components/visualizations/line_chart.vue) as an example.
+   See [`line_chart.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/components/visualizations/line_chart.vue) as an example.
 1. Add your component to the list of conditional imports in [`panel_base.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/vue_shared/components/customizable_dashboard/panels_base.vue#L13).
 1. Add your component to the schema's list of `AnalyticsVisualization` types in [`analytics_visualizations.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json).
 
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 22b977519be..bd35d8f237f 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -1671,7 +1671,7 @@ When [using Vuex](#using-with-vuex), disable the cache when:
 
 - The data is being cached elsewhere
 - The use case does not need caching
-if the data is being cached elsewhere, or if there is no need for it for the given use case.
+  if the data is being cached elsewhere, or if there is no need for it for the given use case.
 
 ```javascript
 import createDefaultClient from '~/lib/graphql';
@@ -1767,12 +1767,12 @@ To improve performance, sometimes we want to make initial GraphQL queries early.
   ```
 
 - Add startup calls with correct variables to the HAML file that serves as a view
-for your application. To add GraphQL startup calls, we use
-`add_page_startup_graphql_call` helper where the first parameter is a path to the
-query, the second one is an object containing query variables. Path to the query is
-relative to `app/graphql/queries` folder: for example, if we need a
-`app/graphql/queries/repository/files.query.graphql` query, the path is
-`repository/files`.
+  for your application. To add GraphQL startup calls, we use
+  `add_page_startup_graphql_call` helper where the first parameter is a path to the
+  query, the second one is an object containing query variables. Path to the query is
+  relative to `app/graphql/queries` folder: for example, if we need a
+  `app/graphql/queries/repository/files.query.graphql` query, the path is
+  `repository/files`.
 
 ## Troubleshooting
 
diff --git a/doc/development/fe_guide/haml.md b/doc/development/fe_guide/haml.md
index 88f4a785a70..4a6b349bbc8 100644
--- a/doc/development/fe_guide/haml.md
+++ b/doc/development/fe_guide/haml.md
@@ -20,8 +20,8 @@ used in HAML:
 - Some of the Pajamas components are available as a [ViewComponent](view_component.md#pajamas-components). Use these when possible.
 - If no ViewComponent exists, why not go ahead and create it? Talk to the Foundations team if you need help.
 - As a fallback, this can be done by applying the correct CSS classes to the elements.
-- A custom
-[Ruby on Rails form builder](https://gitlab.com/gitlab-org/gitlab/-/blob/7c108df101e86d8a27d69df2b5b1ff1fc24133c5/lib/gitlab/form_builders/gitlab_ui_form_builder.rb) exists to help use GitLab UI components in HAML forms.
+- A custom [Ruby on Rails form builder](https://gitlab.com/gitlab-org/gitlab/-/blob/7c108df101e86d8a27d69df2b5b1ff1fc24133c5/lib/gitlab/form_builders/gitlab_ui_form_builder.rb)
+  exists to help use GitLab UI components in HAML forms.
 
 ### Use the GitLab UI form builder
 
diff --git a/doc/development/fe_guide/storybook.md b/doc/development/fe_guide/storybook.md
index 05d4397933f..f0233f71ad2 100644
--- a/doc/development/fe_guide/storybook.md
+++ b/doc/development/fe_guide/storybook.md
@@ -68,7 +68,7 @@ To add a story with API access:
    If you test against `gitlab.com`, make sure to use a token with `read_api` if possible and to make the token short-lived.
 
 1. Create an `.env` file in the `storybook` directory. Use the `storybook/.env.template` file as
-a starting point.
+   a starting point.
 
 1. Set the `API_ACCESS_TOKEN` variable to the access token that you created.
 
diff --git a/doc/development/fe_guide/style/vue.md b/doc/development/fe_guide/style/vue.md
index 83d725d453b..870a4c51915 100644
--- a/doc/development/fe_guide/style/vue.md
+++ b/doc/development/fe_guide/style/vue.md
@@ -123,7 +123,7 @@ Check the [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) for mor
 ## Naming
 
 1. **Extensions**: Use `.vue` extension for Vue components. Do not use `.js` as file extension
-([#34371](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/34371)).
+   ([#34371](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/34371)).
 1. **Reference Naming**: Use PascalCase for their default imports:
 
    ```javascript
@@ -142,7 +142,7 @@ Check the [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) for mor
    };
    ```
 
-1. **Props Naming:**  Avoid using DOM component prop names.
+1. **Props Naming:** Avoid using DOM component prop names.
 1. **Props Naming:** Use kebab-case instead of camelCase to provide props in templates.
 
    ```html
@@ -582,8 +582,8 @@ describe('MyComponent', () => {
 ### Setting component state
 
 1. Avoid using [`setProps`](https://v1.test-utils.vuejs.org/api/wrapper/#setprops) to set
-component state wherever possible. Instead, set the component's
-[`propsData`](https://v1.test-utils.vuejs.org/api/options.html#propsdata) when mounting the component:
+   component state wherever possible. Instead, set the component's
+   [`propsData`](https://v1.test-utils.vuejs.org/api/options.html#propsdata) when mounting the component:
 
    ```javascript
    // bad
@@ -603,7 +603,7 @@ component state wherever possible. Instead, set the component's
 ### Accessing component state
 
 1. When accessing props or attributes, prefer the `wrapper.props('myProp')` syntax over
-`wrapper.props().myProp` or `wrapper.vm.myProp`:
+   `wrapper.props().myProp` or `wrapper.vm.myProp`:
 
    ```javascript
    // good
@@ -616,7 +616,7 @@ component state wherever possible. Instead, set the component's
    ```
 
 1. When asserting multiple props, check the deep equality of the `props()` object with
-[`toEqual`](https://jestjs.io/docs/expect#toequalvalue):
+   [`toEqual`](https://jestjs.io/docs/expect#toequalvalue):
 
    ```javascript
    // good
@@ -633,8 +633,8 @@ component state wherever possible. Instead, set the component's
    ```
 
 1. If you are only interested in some of the props, you can use
-[`toMatchObject`](https://jestjs.io/docs/expect#tomatchobjectobject). Prefer `toMatchObject`
-over [`expect.objectContaining`](https://jestjs.io/docs/expect#expectobjectcontainingobject):
+   [`toMatchObject`](https://jestjs.io/docs/expect#tomatchobjectobject). Prefer `toMatchObject`
+   over [`expect.objectContaining`](https://jestjs.io/docs/expect#expectobjectcontainingobject):
 
    ```javascript
    // good
@@ -652,7 +652,7 @@ over [`expect.objectContaining`](https://jestjs.io/docs/expect#expectobjectconta
 
 ### Testing props validation
 
-1. When checking component props use `assertProps` helper. Props validation failures will be thrown as errors
+When checking component props use `assertProps` helper. Props validation failures will be thrown as errors:
 
 ```javascript
 import { assertProps } from 'helpers/assert_props'
@@ -668,12 +668,12 @@ The goal of this accord is to make sure we are all on the same page.
 
 1. When writing Vue, you may not use jQuery in your application.
    1. If you need to grab data from the DOM, you may query the DOM 1 time while bootstrapping your
-   application to grab data attributes using `dataset`. You can do this without jQuery.
+      application to grab data attributes using `dataset`. You can do this without jQuery.
    1. You may use a jQuery dependency in Vue.js following [this example from the docs](https://vuejs.org/v2/examples/select2.html).
    1. If an outside jQuery Event needs to be listen to inside the Vue application, you may use
-   jQuery event listeners.
+      jQuery event listeners.
    1. We avoid adding new jQuery events when they are not required. Instead of adding new jQuery
-   events take a look at [different methods to do the same task](https://v2.vuejs.org/v2/api/#vm-emit).
+      events take a look at [different methods to do the same task](https://v2.vuejs.org/v2/api/#vm-emit).
 1. You may query the `window` object one time, while bootstrapping your application for application
    specific data (for example, `scrollTo` is ok to access anytime). Do this access during the
    bootstrapping of your application.
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 69967a5a2be..cf7659d0fc0 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -543,7 +543,7 @@ Based on the Vue guidance:
 - **Do not** use or create a JavaScript class in your [data function](https://v2.vuejs.org/v2/api/#data).
 - **Do not** add new JavaScript class implementations.
 - **Do** use [GraphQL](../api_graphql_styleguide.md), [Vuex](vuex.md) or a set of components if
-cannot use primitives or objects.
+  cannot use primitives or objects.
 - **Do** maintain existing implementations using such approaches.
 - **Do** Migrate components to a pure object model when there are substantial changes to it.
 - **Do** add business logic to helpers or utilities, so you can test them separately from your component.
@@ -555,7 +555,7 @@ Additional reasons why having a JavaScript class presents maintainability issues
 - After a class is created, it can be extended in a way that can infringe Vue reactivity and best practices.
 - A class adds a layer of abstraction, which makes the component API and its inner workings less clear.
 - It makes it harder to test. Because the class is instantiated by the component data function, it is
-harder to 'manage' component and class separately.
+  harder to 'manage' component and class separately.
 - Adding Object Oriented Principles (OOP) to a functional codebase adds another way of writing code, reducing consistency and clarity.
 
 ## Style guide
@@ -831,7 +831,7 @@ describe('~/todos/app.vue', () => {
 
 1. Test any directive that defines if/how child component is rendered (for example, `v-if` and `v-for`).
 1. Test any props we are passing to child components (especially if the prop is calculated in the
-component under test, with the `computed` property, for example). Remember to use `.props()` and not `.vm.someProp`.
+   component under test, with the `computed` property, for example). Remember to use `.props()` and not `.vm.someProp`.
 1. Test we react correctly to any events emitted from child components:
 
   ```javascript
diff --git a/doc/development/packages/cleanup_policies.md b/doc/development/packages/cleanup_policies.md
index bbec6ce0623..789bb408dd7 100644
--- a/doc/development/packages/cleanup_policies.md
+++ b/doc/development/packages/cleanup_policies.md
@@ -27,7 +27,7 @@ The parameters are split into two groups:
 - The parameters that define tags to destroy:
   - `older_than`. Destroy tags older than this timestamp.
   - `name_regex`. Destroy tags matching this regular expression.
-  
+
 The remaining parameters impact when the policy is executed:
 
 - `enabled`. Defines if the policy is enabled or not.
@@ -41,8 +41,7 @@ follows this design.
 
 - Policy executions are limited in time.
 - Policy executions are either complete or partial.
-- The background jobs will consider the next job to be executed based on two
-priorities:
+- The background jobs will consider the next job to be executed based on two priorities:
   - Policy with a `next_run_at` in the past.
   - Partially executed policies.
 
@@ -54,7 +53,7 @@ Background jobs for this execution are organized on:
 
 - A cron background job that runs every hour.
 - A set of background jobs that will loop on container repositories that need
-a policy execution.
+  a policy execution.
 
 #### The cron background job
 
@@ -63,7 +62,7 @@ is quite simple.
 Its main tasks are:
 
 1. Check if there are any container repositories in need of a cleanup. If any,
-enqueue as many limited capacity jobs as necessary, up to a limit.
+   enqueue as many limited capacity jobs as necessary, up to a limit.
 1. Compute metrics for cleanup policies and log them.
 
 #### The limited capacity job
@@ -97,14 +96,14 @@ flowchart TD
 ```
 
 - [`ContainerExpirationPolicies::CleanupService`](https://gitlab.com/gitlab-org/gitlab/-/blob/6546ffc6fe4e9b447a1b7f050edddb8926fe4a3d/app/services/container_expiration_policies/cleanup_service.rb).
-This service mainly deals with container repository `expiration_policy_cleanup_status`
-updates and will call the cleanup tags service.
+  This service mainly deals with container repository `expiration_policy_cleanup_status`
+  updates and will call the cleanup tags service.
 - [`Projects::ContainerRepository::CleanupTagsService`](https://gitlab.com/gitlab-org/gitlab/-/blob/f23d70b7d638c38d71af102cfd32a3f6751596f9/app/services/projects/container_repository/cleanup_tags_service.rb).
-This service receives the policy parameters and builds the list of tags to
-destroy on the container registry.
+  This service receives the policy parameters and builds the list of tags to
+  destroy on the container registry.
 - [`Projects::ContainerRepository::DeleteTagsService`](https://gitlab.com/gitlab-org/gitlab/-/blob/f23d70b7d638c38d71af102cfd32a3f6751596f9/app/services/projects/container_repository/delete_tags_service.rb).
-This service receives a list of tags and loops on that list. For each tag,
-the service will call the container registry API endpoint to destroy the target tag.
+  This service receives a list of tags and loops on that list. For each tag,
+  the service will call the container registry API endpoint to destroy the target tag.
 
 The cleanup tags service uses a very specific [execution order](../../user/packages/container_registry/reduce_container_registry_storage.md#how-the-cleanup-policy-works)
 to build the list of tags to destroy.
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index 81399c7ce05..99852645914 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -349,7 +349,7 @@ possible).
 
 | Tests path | Testing engine | Notes |
 | ---------- | -------------- | ----- |
-| `spec/features/` | [Capybara](https://github.com/teamcapybara/capybara) + [RSpec](https://github.com/rspec/rspec-rails#feature-specs) | If your test has the `:js` metadata, the browser driver is [Poltergeist](https://github.com/teamcapybara/capybara#poltergeist), otherwise it's using [RackTest](https://github.com/teamcapybara/capybara#racktest). |
+| `spec/features/` | [Capybara](https://github.com/teamcapybara/capybara) + [RSpec](https://github.com/rspec/rspec-rails#feature-specs) | If your test has the `:js` metadata, the browser driver is [Selenium](https://github.com/teamcapybara/capybara#selenium), otherwise it's using [RackTest](https://github.com/teamcapybara/capybara#racktest). |
 
 ### Frontend feature tests
 
diff --git a/doc/index.md b/doc/index.md
index 617ed547f77..5fdb2386771 100644
--- a/doc/index.md
+++ b/doc/index.md
@@ -37,14 +37,14 @@ Have a look at some of our most popular topics:
 |:-------------------------------------------------------------------------------------------|:------------|
 | [Two-factor authentication](user/profile/account/two_factor_authentication.md)             | Improve the security of your GitLab account. |
 | [GitLab groups](user/group/index.md)                                                       | Manage projects together. |
-| [Keyword reference for the `.gitlab-ci.yml` file](ci/yaml/index.md)                        | Available configuration options for `.gitlab-ci.yml` files. |
-| [Activate GitLab EE with a license](administration/license.md)                            | Activate GitLab Enterprise Edition functionality with a license. |
-| [Back up and restore GitLab](administration/backup_restore/index.md)                                  | Backing up and restoring GitLab self-managed instances. |
+| [CI/CD YAML syntax reference](ci/yaml/index.md)                                            | Available configuration options for `.gitlab-ci.yml` files. |
+| [Activate GitLab EE with a license](administration/license.md)                             | Activate GitLab Enterprise Edition functionality with a license. |
+| [Back up and restore GitLab](administration/backup_restore/index.md)                       | Backing up and restoring GitLab self-managed instances. |
 | [GitLab release and maintenance policy](policy/maintenance.md)                             | Policies for version naming and cadence, and also upgrade recommendations. |
 | [Elasticsearch integration](integration/advanced_search/elasticsearch.md)                  | Integrate Elasticsearch with GitLab to enable advanced search. |
-| [Database settings for Linux package installations](https://docs.gitlab.com/omnibus/settings/database.html) | Database settings for self-managed instances installed using Linux packages. |
-| [NGINX settings for Linux package installations](https://docs.gitlab.com/omnibus/settings/nginx.html)       | NGINX settings for self-managed instances installed using Linux packages. |
-| [SSL configuration for Linux package installations](https://docs.gitlab.com/omnibus/settings/ssl/index.html)      | SSL settings for self-managed instances installed using Linux packages. |
+| [Database settings for Linux package installations](https://docs.gitlab.com/omnibus/settings/database.html)  | Database settings for self-managed instances installed using Linux packages. |
+| [NGINX settings for Linux package installations](https://docs.gitlab.com/omnibus/settings/nginx.html)        | NGINX settings for self-managed instances installed using Linux packages. |
+| [SSL configuration for Linux package installations](https://docs.gitlab.com/omnibus/settings/ssl/index.html) | SSL settings for self-managed instances installed using Linux packages. |
 | [GitLab.com settings](user/gitlab_com/index.md)                                            | Settings used for GitLab.com. |
 
 ## User account
diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md
index 630123510a9..dc7bc225e39 100644
--- a/doc/topics/autodevops/customize.md
+++ b/doc/topics/autodevops/customize.md
@@ -266,12 +266,12 @@ To add custom behaviors to the CI/CD pipeline used by Auto DevOps:
    ```
 
 1. Add your changes to the `.gitlab-ci.yml` file. Your changes are merged with the Auto DevOps template. For more information about
-how `include` merges your changes, see [the `include` documentation](../../ci/yaml/index.md#include).
+   how `include` merges your changes, see [the `include` documentation](../../ci/yaml/index.md#include).
 
 To remove behaviors from the Auto DevOps pipeline:
 
 1. Copy the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
-into your project.
+   into your project.
 1. Edit your copy of the template as needed.
 
 ### Use individual components of Auto DevOps
diff --git a/doc/user/application_security/continuous_vulnerability_scanning/index.md b/doc/user/application_security/continuous_vulnerability_scanning/index.md
index 4d6d48012ae..7d083ea1846 100644
--- a/doc/user/application_security/continuous_vulnerability_scanning/index.md
+++ b/doc/user/application_security/continuous_vulnerability_scanning/index.md
@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/427424) in GitLab 16.7 with an additional feature flag named `global_dependency_scanning_on_advisory_ingestion`. Enabled by default.
 
 FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature, an administrator can [disable the feature flags](../../feature_flags.md) named `dependency_scanning_on_advisory_ingestion` and `package_metadata_advisory_sync`.
+On self-managed GitLab, by default this feature is available. To hide the feature, an administrator can [disable the feature flags](../../feature_flags.md) named `dependency_scanning_on_advisory_ingestion`.
 On GitLab.com, this feature is available.
 
 Continuous Vulnerability Scanning detects new vulnerabilities outside a pipeline.
diff --git a/doc/user/clusters/management_project.md b/doc/user/clusters/management_project.md
index 178f1bd7705..391541d98af 100644
--- a/doc/user/clusters/management_project.md
+++ b/doc/user/clusters/management_project.md
@@ -47,7 +47,7 @@ Management projects are restricted to the following:
 To use a cluster management project to manage your cluster:
 
 1. Create a new project to serve as the cluster management project
-for your cluster.
+   for your cluster.
 1. [Associate the cluster with the management project](#associate-the-cluster-management-project-with-the-cluster).
 1. [Configure your cluster's pipelines](#configuring-your-pipeline).
 1. [Set the environment scope](#setting-the-environment-scope).
@@ -66,7 +66,7 @@ To associate a cluster management project with your cluster:
      1. Select **Kubernetes**.
 1. Expand **Advanced settings**.
 1. From the **Cluster management project** dropdown list, select the cluster management project
-you created in the previous step.
+   you created in the previous step.
 
 ### Configuring your pipeline
 
diff --git a/doc/user/infrastructure/clusters/connect/new_gke_cluster.md b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
index 3b20125ff03..839bce217b7 100644
--- a/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
+++ b/doc/user/infrastructure/clusters/connect/new_gke_cluster.md
@@ -52,7 +52,7 @@ To import the project:
 This project provides you with:
 
 - A [cluster on Google Cloud Platform (GCP)](https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-gke/-/blob/master/gke.tf)
-with defaults for name, location, node count, and Kubernetes version.
+  with defaults for name, location, node count, and Kubernetes version.
 - The [GitLab agent for Kubernetes](https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-gke/-/blob/master/agent.tf) installed in the cluster.
 
 ## Register the agent
@@ -73,10 +73,10 @@ To create a GitLab agent for Kubernetes:
 To set up your project to communicate to GCP and the GitLab API:
 
 1. To authenticate GCP with GitLab, create a [GCP service account](https://cloud.google.com/docs/authentication#service-accounts)
-with following roles: `Compute Network Viewer`, `Kubernetes Engine Admin`, `Service Account User`, and `Service Account Admin`. Both User and Admin
-service accounts are necessary. The User role impersonates the [default service account](https://cloud.google.com/compute/docs/access/service-accounts#default_service_account)
-when [creating the node pool](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/using_gke_with_terraform#node-pool-management).
-The Admin role creates a service account in the `kube-system` namespace.
+   with following roles: `Compute Network Viewer`, `Kubernetes Engine Admin`, `Service Account User`, and `Service Account Admin`. Both User and Admin
+   service accounts are necessary. The User role impersonates the [default service account](https://cloud.google.com/compute/docs/access/service-accounts#default_service_account)
+   when [creating the node pool](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/using_gke_with_terraform#node-pool-management).
+   The Admin role creates a service account in the `kube-system` namespace.
 1. Download the JSON file with the service account key you created in the previous step.
 1. On your computer, encode the JSON file to `base64` (replace `/path/to/sa-key.json` to the path to your key):
 
diff --git a/doc/user/infrastructure/iac/index.md b/doc/user/infrastructure/iac/index.md
index d76f5dd736a..616e15dc230 100644
--- a/doc/user/infrastructure/iac/index.md
+++ b/doc/user/infrastructure/iac/index.md
@@ -84,13 +84,13 @@ To use a Terraform template:
 
    ```yaml
    variables:
-    TF_STATE_NAME: default
-    # If your terraform files are in a subdirectory, set TF_ROOT accordingly. For example:
-    # TF_ROOT: terraform/production
+     TF_STATE_NAME: default
+     # If your terraform files are in a subdirectory, set TF_ROOT accordingly. For example:
+     # TF_ROOT: terraform/production
    ```
 
 1. Optional. Override in your `.gitlab-ci.yml` file the attributes present
-in the template you fetched to customize your configuration.
+   in the template you fetched to customize your configuration.
 
 ### Terraform template recipes
 
diff --git a/doc/user/packages/conan_repository/index.md b/doc/user/packages/conan_repository/index.md
index 56ea4fe74b4..72f36ca4e80 100644
--- a/doc/user/packages/conan_repository/index.md
+++ b/doc/user/packages/conan_repository/index.md
@@ -318,11 +318,11 @@ To search by full or partial package name, or by exact recipe, run the
 The scope of your search depends on your Conan remote configuration:
 
 - If you have a remote configured for your [instance](#add-a-remote-for-your-instance), your search includes
-all projects you have permission to access. This includes your private projects
- as well as all public projects.
+  all projects you have permission to access. This includes your private projects
+  as well as all public projects.
 
 - If you have a remote configured for a [project](#add-a-remote-for-your-project), your search includes all
-packages in the target project, as long as you have permission to access it.
+  packages in the target project, as long as you have permission to access it.
 
 NOTE:
 The limit of the search results is 500 packages, and the results are sorted by the most recently published packages.
diff --git a/doc/user/packages/container_registry/reduce_container_registry_storage.md b/doc/user/packages/container_registry/reduce_container_registry_storage.md
index 614639c705f..de24f2618d5 100644
--- a/doc/user/packages/container_registry/reduce_container_registry_storage.md
+++ b/doc/user/packages/container_registry/reduce_container_registry_storage.md
@@ -191,14 +191,14 @@ To create a cleanup policy in the UI:
 1. In the **Cleanup policies** section, select **Set cleanup rules**.
 1. Complete the fields:
 
-   | Field                      | Description                                     |
-   |----------------------------|-------------------------------------------------|
-   | **Toggle**                 | Turn the policy on or off.                      |
-   | **Run cleanup**            | How often the policy should run.                |
-   | **Keep the most recent**   | How many tags to _always_ keep for each image.  |
+   | Field                      | Description |
+   |----------------------------|-------------|
+   | **Toggle**                 | Turn the policy on or off. |
+   | **Run cleanup**            | How often the policy should run. |
+   | **Keep the most recent**   | How many tags to _always_ keep for each image. |
    | **Keep tags matching**     | A regex pattern that determines which tags to preserve. The `latest` tag is always preserved. For all tags, use `.*`. See other [regex pattern examples](#regex-pattern-examples). |
-   | **Remove tags older than** | Remove only tags older than X days.             |
-   | **Remove tags matching**   | A regex pattern that determines which tags to remove. This value cannot be blank. For all tags, use `.*`. See other [regex pattern examples](#regex-pattern-examples).             |
+   | **Remove tags older than** | Remove only tags older than X days. |
+   | **Remove tags matching**   | A regex pattern that determines which tags to remove. This value cannot be blank. For all tags, use `.*`. See other [regex pattern examples](#regex-pattern-examples). |
 
 1. Select **Save**.
 
@@ -275,9 +275,9 @@ You can use the following application settings to prevent server resource starva
 
 For self-managed instances, those settings can be updated in the [Rails console](../../../administration/operations/rails_console.md#starting-a-rails-console-session):
 
-  ```ruby
-  ApplicationSetting.last.update(container_registry_expiration_policies_worker_capacity: 3)
-  ```
+```ruby
+ApplicationSetting.last.update(container_registry_expiration_policies_worker_capacity: 3)
+```
 
 They are also available in the [administrator area](../../../administration/admin_area.md):
 
@@ -292,7 +292,7 @@ You can set, update, and disable the cleanup policies using the GitLab API.
 Examples:
 
 - Select all tags, keep at least 1 tag per image, clean up any tag older than 14 days, run once a month, preserve
-any images with the name `main`, and the policy is enabled:
+  any images with the name `main`, and the policy is enabled:
 
   ```shell
   curl --request PUT --header 'Content-Type: application/json;charset=UTF-8' --header "PRIVATE-TOKEN: <your_access_token>" \
diff --git a/doc/user/packages/maven_repository/index.md b/doc/user/packages/maven_repository/index.md
index 8f702183adc..118be200a4f 100644
--- a/doc/user/packages/maven_repository/index.md
+++ b/doc/user/packages/maven_repository/index.md
@@ -255,9 +255,9 @@ credentials += Credentials("GitLab Packages Registry", "<host>", "<name>", "<tok
 In this example:
 
 - `<endpoint url>` is the [endpoint URL](#endpoint-urls).
-Example: `https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven`.
+  Example: `https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven`.
 - `<host>` is the host present in the `<endpoint url>` without the protocol
-scheme or the port. Example: `gitlab.example.com`.
+  scheme or the port. Example: `gitlab.example.com`.
 - `<name>` and `<token>` are explained in the table above.
 
 ::EndTabs
@@ -289,11 +289,11 @@ For the instance-level endpoint, ensure the relevant section of your `pom.xml` i
 
 #### Endpoint URLs
 
-| Endpoint | Endpoint URL for `pom.xml`                                               | Additional information                                                                                                             |
-| -------- | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
+| Endpoint | Endpoint URL for `pom.xml`                                               | Additional information |
+|----------|--------------------------------------------------------------------------|------------------------|
 | Project  | `https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven` | Replace `gitlab.example.com` with your domain name. Replace `<project_id>` with your project ID, found on your project's homepage. |
-| Group    | `https://gitlab.example.com/api/v4/groups/<group_id>/-/packages/maven`   | Replace `gitlab.example.com` with your domain name. Replace `<group_id>` with your group ID, found on your group's homepage.      |
-| Instance | `https://gitlab.example.com/api/v4/packages/maven`                       | Replace `gitlab.example.com` with your domain name.                                                                                |
+| Group    | `https://gitlab.example.com/api/v4/groups/<group_id>/-/packages/maven`   | Replace `gitlab.example.com` with your domain name. Replace `<group_id>` with your group ID, found on your group's homepage. |
+| Instance | `https://gitlab.example.com/api/v4/packages/maven`                       | Replace `gitlab.example.com` with your domain name. |
 
 ### Edit the configuration file for publishing
 
diff --git a/doc/user/project/clusters/add_existing_cluster.md b/doc/user/project/clusters/add_existing_cluster.md
index 161a698a48c..ea4c345a592 100644
--- a/doc/user/project/clusters/add_existing_cluster.md
+++ b/doc/user/project/clusters/add_existing_cluster.md
@@ -25,7 +25,7 @@ See the prerequisites below to add existing clusters to GitLab.
 To add any cluster to GitLab, you need:
 
 - Either a GitLab.com account or an account for a self-managed installation
-running GitLab 12.5 or later.
+  running GitLab 12.5 or later.
 - The Maintainer role for group-level and project-level clusters.
 - Access to the Admin Area for instance-level clusters.
 - A Kubernetes cluster.
@@ -48,7 +48,7 @@ To add an existing **EKS** cluster, you need:
 
 - An Amazon EKS cluster with worker nodes properly configured.
 - `kubectl` [installed and configured](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html#get-started-kubectl)
-for access to the EKS cluster.
+  for access to the EKS cluster.
 - Ensure the token of the account has administrator privileges for the cluster.
 
 ### GKE clusters
@@ -56,8 +56,8 @@ for access to the EKS cluster.
 To add an existing **GKE** cluster, you need:
 
 - The `container.clusterRoleBindings.create` permission to create a cluster
-role binding. You can follow the [Google Cloud documentation](https://cloud.google.com/iam/docs/granting-changing-revoking-access)
-to grant access.
+  role binding. You can follow the [Google Cloud documentation](https://cloud.google.com/iam/docs/granting-changing-revoking-access)
+  to grant access.
 
 ## How to add an existing cluster
 
diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md
index 940561d70d0..7d18ef0d1e4 100644
--- a/doc/user/project/clusters/add_remove_clusters.md
+++ b/doc/user/project/clusters/add_remove_clusters.md
@@ -39,7 +39,7 @@ When removing a cluster integration, you have two options:
 
 - **Remove integration**: remove only the Kubernetes integration.
 - **Remove integration and resources**: remove the cluster integration and
-all GitLab cluster-related resources such as namespaces, roles, and bindings.
+  all GitLab cluster-related resources such as namespaces, roles, and bindings.
 
 To remove the Kubernetes cluster integration:
 
diff --git a/doc/user/project/repository/code_suggestions/index.md b/doc/user/project/repository/code_suggestions/index.md
index 6a1d8fbe66e..2315778e0f2 100644
--- a/doc/user/project/repository/code_suggestions/index.md
+++ b/doc/user/project/repository/code_suggestions/index.md
@@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Write code more efficiently by using generative AI to suggest code while you're developing.
 
-With Code Suggestions, you get:
+With [GitLab Duo Code Suggestions](https://about.gitlab.com/solutions/code-suggestions/), you get:
 
 - Code Completion, which suggests completions to the current line you are typing. These suggestions are usually low latency.
 - Code Generation, which generates code based on a natural language code
@@ -26,7 +26,7 @@ With Code Suggestions, you get:
 
 GitLab Duo Code Suggestions are available:
 
-- On [self-managed](self_managed.md) and [SaaS](saas.md). View these pages to get started.
+- In the Premium and Ultimate tier for [self-managed](self_managed.md), and across all tiers for [SaaS](saas.md). View these pages to get started.
 - In VS Code, Microsoft Visual Studio, JetBrains IDEs, and Neovim. You must have the corresponding GitLab extension installed.
 - In the GitLab Web IDE.
 
diff --git a/doc/user/project/repository/code_suggestions/self_managed.md b/doc/user/project/repository/code_suggestions/self_managed.md
index f16b1b05abb..5688985ab49 100644
--- a/doc/user/project/repository/code_suggestions/self_managed.md
+++ b/doc/user/project/repository/code_suggestions/self_managed.md
@@ -4,7 +4,7 @@ group: Code Creation
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Code Suggestions on self-managed GitLab **(SELF)**
+# Code Suggestions on self-managed GitLab **(PREMIUM SELF)**
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10653) in GitLab 16.1 as [Beta](../../../../policy/experiment-beta-support.md#beta) on self-managed GitLab.
 > - [Introduced support for Google Vertex AI Codey APIs](https://gitlab.com/groups/gitlab-org/-/epics/10562) in GitLab 16.1.
@@ -41,7 +41,7 @@ version of GitLab. This setting is visible only in self-managed GitLab instances
 
 ::Tabs
 
-:::TabTitle GitLab 16.3 and later **(PREMIUM)**
+:::TabTitle GitLab 16.3 and later
 
 Prerequisites:
 
diff --git a/doc/user/project/repository/reducing_the_repo_size_using_git.md b/doc/user/project/repository/reducing_the_repo_size_using_git.md
index a060973d89f..528e9eefa44 100644
--- a/doc/user/project/repository/reducing_the_repo_size_using_git.md
+++ b/doc/user/project/repository/reducing_the_repo_size_using_git.md
@@ -190,7 +190,7 @@ no longer being available.
 
 To clean up a repository:
 
-1. Go to the project for the repository.
+1. On the left sidebar, select **Search or go to** and find your project.
 1. Go to **Settings > Repository**.
 1. Upload a list of objects. For example, a `commit-map` file created by `git filter-repo` which is located in the
    `filter-repo` directory.