Add latest changes from gitlab-org/gitlab@master

131 files changed, 550 insertions, 616 deletions

diff --git a/app/assets/javascripts/work_items/components/work_item_assignees.vue b/app/assets/javascripts/work_items/components/work_item_assignees.vue
index 9ff424aa20f..f1b12e6478f 100644
--- a/app/assets/javascripts/work_items/components/work_item_assignees.vue
+++ b/app/assets/javascripts/work_items/components/work_item_assignees.vue
@@ -18,11 +18,17 @@ import { n__, s__ } from '~/locale';
 import Tracking from '~/tracking';
 import SidebarParticipant from '~/sidebar/components/assignees/sidebar_participant.vue';
 import { DEFAULT_DEBOUNCE_AND_THROTTLE_MS } from '~/lib/utils/constants';
-import localUpdateWorkItemMutation from '../graphql/local_update_work_item.mutation.graphql';
+import updateWorkItemMutation from '../graphql/update_work_item.mutation.graphql';
 import { i18n, TRACKING_CATEGORY_SHOW } from '../constants';
 
 function isTokenSelectorElement(el) {
-  return el?.classList.contains('gl-token-close') || el?.classList.contains('dropdown-item');
+  return (
+    el?.classList.contains('gl-token-close') ||
+    el?.classList.contains('dropdown-item') ||
+    // TODO: replace this logic when we have a class added to clear-all button in GitLab UI
+    (el?.classList.contains('gl-button') &&
+      el?.closest('.form-control')?.classList.contains('gl-token-selector'))
+  );
 }
 
 function addClass(el) {
@@ -130,7 +136,7 @@ export default {
         if (this.searchUsers.some((user) => user.username === this.currentUser.username)) {
           return this.moveCurrentUserToStart(this.searchUsers);
         }
-        return [this.currentUser, ...this.searchUsers];
+        return [addClass(this.currentUser), ...this.searchUsers];
       }
       return this.searchUsers;
     },
@@ -142,12 +148,18 @@ export default {
         ? s__('WorkItem|Add assignees')
         : s__('WorkItem|Add assignee');
     },
+    assigneeIds() {
+      return this.localAssignees.map(({ id }) => id);
+    },
   },
   watch: {
-    assignees(newVal) {
-      if (!this.isEditing) {
-        this.localAssignees = newVal.map(addClass);
-      }
+    assignees: {
+      handler(newVal) {
+        if (!this.isEditing) {
+          this.localAssignees = newVal.map(addClass);
+        }
+      },
+      deep: true,
     },
   },
   created() {
@@ -169,19 +181,33 @@ export default {
     handleBlur(e) {
       if (isTokenSelectorElement(e.relatedTarget) || !this.isEditing) return;
       this.isEditing = false;
-      this.setAssignees(this.localAssignees);
+      this.setAssignees(this.assigneeIds);
     },
-    setAssignees(assignees) {
-      this.$apollo.mutate({
-        mutation: localUpdateWorkItemMutation,
-        variables: {
-          input: {
-            id: this.workItemId,
-            assignees,
+    async setAssignees(assigneeIds) {
+      try {
+        const {
+          data: {
+            workItemUpdate: { errors },
+          },
+        } = await this.$apollo.mutate({
+          mutation: updateWorkItemMutation,
+          variables: {
+            input: {
+              id: this.workItemId,
+              assigneesWidget: {
+                assigneeIds,
+              },
+            },
           },
-        },
-      });
-      this.track('updated_assignees');
+        });
+        if (errors.length > 0) {
+          this.throwUpdateError();
+          return;
+        }
+        this.track('updated_assignees');
+      } catch {
+        this.throwUpdateError();
+      }
     },
     handleFocus() {
       this.isEditing = true;
@@ -205,13 +231,25 @@ export default {
     },
     moveCurrentUserToStart(users = []) {
       if (this.currentUser) {
-        return [this.currentUser, ...users.filter((user) => user.id !== this.currentUser.id)];
+        return [
+          addClass(this.currentUser),
+          ...users.filter((user) => user.id !== this.currentUser.id),
+        ];
       }
       return users;
     },
     closeDropdown() {
       this.$refs.tokenSelector.closeDropdown();
     },
+    assignToCurrentUser() {
+      this.setAssignees([this.currentUser.id]);
+      this.localAssignees = [addClass(this.currentUser)];
+    },
+    throwUpdateError() {
+      this.$emit('error', i18n.updateError);
+      // If mutation is rejected, we're rolling back to initial state
+      this.localAssignees = this.assignees.map(addClass);
+    },
   },
 };
 </script>
@@ -227,11 +265,12 @@ export default {
       ref="tokenSelector"
       :selected-tokens="localAssignees"
       :container-class="containerClass"
-      class="assignees-selector gl-flex-grow-1 gl-border gl-border-white gl-rounded-base col-9 gl-align-self-start gl-px-0!"
       :class="{ 'gl-hover-border-gray-200': canUpdate }"
       :dropdown-items="dropdownItems"
       :loading="isLoadingUsers"
       :view-only="!canUpdate"
+      :allow-clear-all="isEditing"
+      class="assignees-selector gl-flex-grow-1 gl-border gl-border-white gl-rounded-base col-9 gl-align-self-start gl-px-0!"
       @input="handleAssigneesInput"
       @text-input="debouncedSearchKeyUpdate"
       @focus="handleFocus"
@@ -251,7 +290,7 @@ export default {
             size="small"
             class="assign-myself"
             data-testid="assign-self"
-            @click.stop="setAssignees([currentUser])"
+            @click.stop="assignToCurrentUser"
             >{{ __('Assign myself') }}</gl-button
           >
         </div>
diff --git a/app/assets/javascripts/work_items/graphql/provider.js b/app/assets/javascripts/work_items/graphql/provider.js
index 1feef8bcaf8..b70c06fddea 100644
--- a/app/assets/javascripts/work_items/graphql/provider.js
+++ b/app/assets/javascripts/work_items/graphql/provider.js
@@ -2,7 +2,7 @@ import produce from 'immer';
 import Vue from 'vue';
 import VueApollo from 'vue-apollo';
 import createDefaultClient from '~/lib/graphql';
-import { WIDGET_TYPE_ASSIGNEES, WIDGET_TYPE_LABELS } from '../constants';
+import { WIDGET_TYPE_LABELS } from '../constants';
 import typeDefs from './typedefs.graphql';
 import workItemQuery from './work_item.query.graphql';
 
@@ -29,6 +29,11 @@ export const temporaryConfig = {
               );
             },
           },
+          widgets: {
+            merge(_, incoming) {
+              return incoming;
+            },
+          },
         },
       },
     },
@@ -44,13 +49,6 @@ export const resolvers = {
       });
 
       const data = produce(sourceData, (draftData) => {
-        if (input.assignees) {
-          const assigneesWidget = draftData.workItem.widgets.find(
-            (widget) => widget.type === WIDGET_TYPE_ASSIGNEES,
-          );
-          assigneesWidget.assignees.nodes = [...input.assignees];
-        }
-
         if (input.labels) {
           const labelsWidget = draftData.workItem.mockWidgets.find(
             (widget) => widget.type === WIDGET_TYPE_LABELS,
diff --git a/app/models/ci/pipeline.rb b/app/models/ci/pipeline.rb
index 2258491d2e0..4bc8a9dfd54 100644
--- a/app/models/ci/pipeline.rb
+++ b/app/models/ci/pipeline.rb
@@ -603,7 +603,7 @@ module Ci
 
       cancel_jobs(cancelable_statuses, retries: retries, auto_canceled_by_pipeline_id: auto_canceled_by_pipeline_id)
 
-      if cascade_to_children && project.cascade_cancel_pipelines_enabled?
+      if cascade_to_children
         # cancel any bridges that could spin up new child pipelines
         cancel_jobs(bridges_in_self_and_descendants.cancelable, retries: retries, auto_canceled_by_pipeline_id: auto_canceled_by_pipeline_id)
         cancel_children(auto_canceled_by_pipeline_id: auto_canceled_by_pipeline_id, execute_async: execute_async)
diff --git a/app/models/project.rb b/app/models/project.rb
index 539e4bfabec..6b2b0ba1c4b 100644
--- a/app/models/project.rb
+++ b/app/models/project.rb
@@ -1044,12 +1044,6 @@ class Project < ApplicationRecord
     !emails_disabled?
   end
 
-  def cascade_cancel_pipelines_enabled?
-    strong_memoize(:cascade_cancel_pipelines_enabled) do
-      Feature.enabled?(:ci_parent_pipeline_cancels_children, self)
-    end
-  end
-
   override :lfs_enabled?
   def lfs_enabled?
     return namespace.lfs_enabled? if self[:lfs_enabled].nil?
diff --git a/config/feature_flags/development/ci_parent_pipeline_cancels_children.yml b/config/feature_flags/development/ci_parent_pipeline_cancels_children.yml
deleted file mode 100644
index 0c8f722b4c1..00000000000
--- a/config/feature_flags/development/ci_parent_pipeline_cancels_children.yml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-name: ci_parent_pipeline_cancels_children
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82149
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/354528
-milestone: '15.3'
-type: development
-group: group::pipeline execution
-default_enabled: false
diff --git a/config/feature_flags/development/use_redis_hll_instrumentation_classes.yml b/config/feature_flags/development/use_redis_hll_instrumentation_classes.yml
deleted file mode 100644
index 46e53688b70..00000000000
--- a/config/feature_flags/development/use_redis_hll_instrumentation_classes.yml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-name: use_redis_hll_instrumentation_classes
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90237 
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/365332
-milestone: '15.1'
-type: development
-group: group::product intelligence
-default_enabled: false
diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md
index 3ef5d3941eb..64ef27cbf51 100644
--- a/doc/administration/auth/ldap/ldap-troubleshooting.md
+++ b/doc/administration/auth/ldap/ldap-troubleshooting.md
@@ -210,8 +210,8 @@ This shows you which user has this email address. One of two steps must be taken
   remove this email as a secondary email and make it a primary one so GitLab
   associates this profile to the LDAP identity.
 
-The user can do either of these steps [in their
-profile](../../../user/profile/index.md#access-your-user-profile) or an administrator can do it.
+The user can do either of these steps 
+[in their profile](../../../user/profile/index.md#access-your-user-profile) or an administrator can do it.
 
 #### Projects limit errors
 
@@ -426,13 +426,12 @@ Rails.logger.level = Logger::DEBUG
 LdapAllGroupsSyncWorker.new.perform
 ```
 
-Next, [learn how to read the
-output](#example-console-output-after-a-group-sync).
+Next, [learn how to read the output](#example-console-output-after-a-group-sync).
 
 ##### Example console output after a group sync
 
-Like the output from the user sync, the output from the [manual group
-sync](#sync-all-groups) is also very verbose. However, it contains lots
+Like the output from the user sync, the output from the 
+[manual group sync](#sync-all-groups) is also very verbose. However, it contains lots
 of helpful information.
 
 Indicates the point where syncing actually begins:
@@ -743,8 +742,7 @@ For instructions about how to use the rails console, refer to this
 This provides debug output that shows what GitLab is doing and with what.
 This value is not persisted, and is only enabled for this session in the Rails console.
 
-To enable debug output in the rails console, [enter the rails
-console](#rails-console) and run:
+To enable debug output in the rails console, [enter the rails console](#rails-console) and run:
 
 ```ruby
 Rails.logger.level = Logger::DEBUG
diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 60a4cc8706f..8c5bf96e99e 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -250,8 +250,8 @@ but `LocalAccounts` works for authenticating against local, Active Directory acc
    <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email" />
    ```
 
-1. For OIDC discovery to work with B2C, the policy must be configured with an issuer compatible with the [OIDC
-   specification](https://openid.net/specs/openid-connect-discovery-1_0.html#rfc.section.4.3).
+1. For OIDC discovery to work with B2C, the policy must be configured with an issuer compatible with the 
+  [OIDC specification](https://openid.net/specs/openid-connect-discovery-1_0.html#rfc.section.4.3).
    See the [token compatibility settings](https://docs.microsoft.com/en-us/azure/active-directory-b2c/configure-tokens?pivots=b2c-custom-policy#token-compatibility-settings).
    In `TrustFrameworkBase.xml` under `JwtIssuer`, set `IssuanceClaimPattern` to `AuthorityWithTfp`:
 
@@ -529,8 +529,7 @@ If you're having trouble, here are some tips:
 
 1. Check your system clock to ensure the time is synchronized properly.
 
-1. As mentioned in [the
-   documentation](https://github.com/m0n9oose/omniauth_openid_connect),
+1. As mentioned in [the documentation](https://github.com/m0n9oose/omniauth_openid_connect),
    make sure `issuer` corresponds to the base URL of the Discovery URL. For
    example, `https://accounts.google.com` is used for the URL
    `https://accounts.google.com/.well-known/openid-configuration`.
@@ -540,5 +539,4 @@ If you're having trouble, here are some tips:
    If you are seeing 401 errors upon retrieving the `userinfo` endpoint, you may
    want to check your OpenID Web server configuration. For example, for
    [`oauth2-server-php`](https://github.com/bshaffer/oauth2-server-php), you
-   may need to [add a configuration parameter to
-   Apache](https://github.com/bshaffer/oauth2-server-php/issues/926#issuecomment-387502778).
+   may need to [add a configuration parameter to Apache](https://github.com/bshaffer/oauth2-server-php/issues/926#issuecomment-387502778).
diff --git a/doc/administration/geo/disaster_recovery/bring_primary_back.md b/doc/administration/geo/disaster_recovery/bring_primary_back.md
index 833b9a877e9..a2d4f35a7c3 100644
--- a/doc/administration/geo/disaster_recovery/bring_primary_back.md
+++ b/doc/administration/geo/disaster_recovery/bring_primary_back.md
@@ -41,8 +41,8 @@ To bring the former **primary** site up to date:
 
    NOTE:
    If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domain-dns-record)
-   for this site during disaster recovery procedure you may need to [block
-   all the writes to this site](planned_failover.md#prevent-updates-to-the-primary-site)
+   for this site during disaster recovery procedure you may need to 
+   [block all the writes to this site](planned_failover.md#prevent-updates-to-the-primary-site)
    during this procedure.
 
 1. [Set up database replication](../setup/database.md). In this case, the **secondary** site
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 81cb4572890..6936c765a59 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -331,8 +331,7 @@ Be sure to restart PostgreSQL for this to take effect. See the
 This occurs when PostgreSQL does not have a replication slot for the
 **secondary** node by that name.
 
-You may want to rerun the [replication
-process](../setup/database.md) on the **secondary** node .
+You may want to rerun the [replication process](../setup/database.md) on the **secondary** node .
 
 ### Message: "Command exceeded allowed execution time" when setting up replication?
 
@@ -869,9 +868,8 @@ or `gitlab-ctl promote-to-primary-node`, either:
   ```
 
 - Upgrade to GitLab 12.6.3 or later if it is safe to do so. For example,
-  if the failover was just a test. A [caching-related
-  bug](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/22021) was
-  fixed.
+  if the failover was just a test. A 
+  [caching-related bug](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/22021) was fixed.
 
 ### Message: `ActiveRecord::RecordInvalid: Validation failed: Enabled Geo primary node cannot be disabled`
 
diff --git a/doc/administration/geo/replication/version_specific_upgrades.md b/doc/administration/geo/replication/version_specific_upgrades.md
index f0925bdf87e..91d87f093c5 100644
--- a/doc/administration/geo/replication/version_specific_upgrades.md
+++ b/doc/administration/geo/replication/version_specific_upgrades.md
@@ -243,8 +243,8 @@ the recommended procedure, see the
 ## Upgrading to GitLab 12.9
 
 WARNING:
-GitLab 12.9.0 through GitLab 12.9.3 are affected by [a bug that stops
-repository verification](https://gitlab.com/gitlab-org/gitlab/-/issues/213523).
+GitLab 12.9.0 through GitLab 12.9.3 are affected by 
+[a bug that stops repository verification](https://gitlab.com/gitlab-org/gitlab/-/issues/213523).
 The issue is fixed in GitLab 12.9.4. Upgrade to GitLab 12.9.4 or later.
 
 By default, GitLab 12.9 attempts to upgrade the embedded PostgreSQL server
@@ -397,6 +397,6 @@ For the recommended procedure, see the
 ## Upgrading to GitLab 12.0
 
 WARNING:
-This version is affected by a [bug that results in new LFS objects not being
-replicated to Geo secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
+This version is affected by a 
+[bug that results in new LFS objects not being replicated to Geo secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
 The issue is fixed in GitLab 12.1. Be sure to upgrade to GitLab 12.1 or later.
diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index e8c290e197b..6c1812b2754 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -112,8 +112,9 @@ gitlab:
 
 Since GitLab 15.1, Geo secondary proxying is enabled by default for separate URLs also.
 
-There are minor known issues linked in the ["Geo secondary proxying with separate URLs"
-epic](https://gitlab.com/groups/gitlab-org/-/epics/6865). You can also add feedback in the epic about any use-cases that
+There are minor known issues linked in the 
+["Geo secondary proxying with separate URLs" epic](https://gitlab.com/groups/gitlab-org/-/epics/6865). 
+You can also add feedback in the epic about any use-cases that
 are not possible anymore with proxying enabled.
 
 If you run into issues, to disable this feature, disable the `geo_secondary_proxy_separate_urls` feature flag.
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index 572dd6b25a2..968ab6551cd 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -1143,8 +1143,7 @@ gitaly['pack_objects_cache_enabled'] = true
 #### `enabled` defaults to `false`
 
 The cache is disabled by default. This is because in some cases, it
-can create an [extreme
-increase](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/4010#note_534564684)
+can create an [extreme increase](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/4010#note_534564684)
 in the number of bytes written to disk. On GitLab.com, we have verified
 that our repository storage disks can handle this extra workload, but
 we felt we cannot assume this is true everywhere.
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 93c976db0f4..3c007ce8ff3 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -97,8 +97,8 @@ If you [installed](https://about.gitlab.com/install/) GitLab using the Omnibus G
 
 ### Preparation
 
-Before beginning, you should already have a working GitLab instance. [Learn how
-to install GitLab](https://about.gitlab.com/install/).
+Before beginning, you should already have a working GitLab instance. 
+[Learn how to install GitLab](https://about.gitlab.com/install/).
 
 Provision a PostgreSQL server. We recommend using the PostgreSQL that is shipped
 with Omnibus GitLab and use it to configure the PostgreSQL database. You can use an
@@ -331,8 +331,8 @@ To configure the additional connection, you must either:
 #### Configure a new PgBouncer database with `pool_mode = session`
 
 We recommend using PgBouncer with `session` pool mode. You can use the
-[bundled PgBouncer](../postgresql/pgbouncer.md) or use an external PgBouncer and [configure it
-manually](https://www.pgbouncer.org/config.html).
+[bundled PgBouncer](../postgresql/pgbouncer.md) or use an external PgBouncer and 
+[configure it manually](https://www.pgbouncer.org/config.html).
 
 The following example uses the bundled PgBouncer and sets up two separate connection pools on PostgreSQL host,
 one in `session` pool mode and the other in `transaction` pool mode. For this example to work,
@@ -620,8 +620,8 @@ Updates to example must be made at:
    gitlab-ctl reconfigure
    ```
 
-1. To ensure that Praefect [has updated its Prometheus listen
-   address](https://gitlab.com/gitlab-org/gitaly/-/issues/2734),
+1. To ensure that Praefect 
+   [has updated its Prometheus listen address](https://gitlab.com/gitlab-org/gitaly/-/issues/2734),
    [restart Praefect](../restart_gitlab.md#omnibus-gitlab-restart):
 
    ```shell
@@ -928,8 +928,8 @@ For more information on Gitaly server configuration, see our
    gitlab-ctl reconfigure
    ```
 
-1. To ensure that Gitaly [has updated its Prometheus listen
-   address](https://gitlab.com/gitlab-org/gitaly/-/issues/2734),
+1. To ensure that Gitaly 
+   [has updated its Prometheus listen address](https://gitlab.com/gitlab-org/gitaly/-/issues/2734),
    [restart Gitaly](../restart_gitlab.md#omnibus-gitlab-restart):
 
    ```shell
@@ -1149,8 +1149,7 @@ running multiple Gitaly storages.
 ### Grafana
 
 Grafana is included with GitLab, and can be used to monitor your Praefect
-cluster. See [Grafana Dashboard
-Service](https://docs.gitlab.com/omnibus/settings/grafana.html)
+cluster. See [Grafana Dashboard Service](https://docs.gitlab.com/omnibus/settings/grafana.html)
 for detailed documentation.
 
 To get started quickly:
diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md
index 53e9c699804..81138a31bc9 100644
--- a/doc/administration/nfs.md
+++ b/doc/administration/nfs.md
@@ -65,8 +65,7 @@ Read:
 ## Known kernel version incompatibilities
 
 RedHat Enterprise Linux (RHEL) and CentOS v7.7 and v7.8 ship with kernel
-version `3.10.0-1127`, which [contains a
-bug](https://bugzilla.redhat.com/show_bug.cgi?id=1783554) that causes
+version `3.10.0-1127`, which [contains a bug](https://bugzilla.redhat.com/show_bug.cgi?id=1783554) that causes
 [uploads to fail to copy over NFS](https://gitlab.com/gitlab-org/gitlab/-/issues/218999). The
 following GitLab versions include a fix to work properly with that
 kernel version:
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index ddeaf0280eb..0299d5f8b0c 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -26,8 +26,8 @@ GitLab has been tested by vendors and customers on a number of object storage pr
 
 ### Known compatibility issues
 
-- Dell EMC ECS: Prior to GitLab 13.3, there is a [known bug in GitLab Workhorse that prevents
-  HTTP Range Requests from working with CI job artifacts](https://gitlab.com/gitlab-org/gitlab/-/issues/223806).
+- Dell EMC ECS: Prior to GitLab 13.3, there is a 
+  [known bug in GitLab Workhorse that prevents HTTP Range Requests from working with CI job artifacts](https://gitlab.com/gitlab-org/gitlab/-/issues/223806).
   Be sure to upgrade to GitLab 13.3.0 or above if you use S3 storage with this hardware.
 
 - Ceph S3 prior to [Kraken 11.0.2](https://ceph.com/releases/kraken-11-0-2-released/) does not support the [Upload Copy Part API](https://gitlab.com/gitlab-org/gitlab/-/issues/300604). You may need to [disable multi-threaded copying](#multi-threaded-copying).
@@ -578,9 +578,8 @@ real bucket into multiple virtual buckets. If your object storage
 bucket is called `my-gitlab-objects` you can configure uploads to go
 into `my-gitlab-objects/uploads`, artifacts into
 `my-gitlab-objects/artifacts`, etc. The application will act as if
-these are separate buckets. Note that use of bucket prefixes [may not
-work correctly with Helm
-backups](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3376).
+these are separate buckets. Note that use of bucket prefixes 
+[may not work correctly with Helm backups](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3376).
 
 Helm-based installs require separate buckets to
 [handle backup restorations](https://docs.gitlab.com/charts/advanced/external-object-storage/#lfs-artifacts-uploads-packages-external-diffs-terraform-state-dependency-proxy).
@@ -693,18 +692,17 @@ configuration.
 
 When configured either with an instance profile or with the consolidated
 object configuration, GitLab Workhorse properly uploads files to S3
-buckets that have [SSE-S3 or SSE-KMS encryption enabled by
-default](https://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html).
-Customer master keys (CMKs) and SSE-C encryption are [not
-supported since this requires sending the encryption keys in every request](https://gitlab.com/gitlab-org/gitlab/-/issues/226006).
+buckets that have [SSE-S3 or SSE-KMS encryption enabled by default](https://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html).
+Customer master keys (CMKs) and SSE-C encryption are 
+[not supported since this requires sending the encryption keys in every request](https://gitlab.com/gitlab-org/gitlab/-/issues/226006).
 
 ##### Server-side encryption headers
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38240) in GitLab 13.3.
 
 Setting a default encryption on an S3 bucket is the easiest way to
-enable encryption, but you may want to [set a bucket policy to ensure
-only encrypted objects are uploaded](https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-store-kms-encrypted-objects/).
+enable encryption, but you may want to 
+[set a bucket policy to ensure only encrypted objects are uploaded](https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-store-kms-encrypted-objects/).
 To do this, you must configure GitLab to send the proper encryption headers
 in the `storage_options` configuration section:
 
diff --git a/doc/administration/operations/extra_sidekiq_processes.md b/doc/administration/operations/extra_sidekiq_processes.md
index 373017eefa7..8117b11896f 100644
--- a/doc/administration/operations/extra_sidekiq_processes.md
+++ b/doc/administration/operations/extra_sidekiq_processes.md
@@ -126,8 +126,8 @@ you list. In this example, we exclude all import-related jobs from a Sidekiq nod
 > - [Renamed from `experimental_queue_selector` to `queue_selector`](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/147) in GitLab 13.6.
 
 In addition to selecting queues by name, as above, the `queue_selector` option
-allows queue groups to be selected in a more general way using a [worker matching
-query](extra_sidekiq_routing.md#worker-matching-query). After `queue_selector`
+allows queue groups to be selected in a more general way using a 
+[worker matching query](extra_sidekiq_routing.md#worker-matching-query). After `queue_selector`
 is set, all `queue_groups` must follow the aforementioned syntax.
 
 In `/etc/gitlab/gitlab.rb`:
@@ -201,8 +201,8 @@ have the concurrency tuned according to:
 - The throughput achieved.
 
 Each thread requires a Redis connection, so adding threads may increase Redis
-latency and potentially cause client timeouts. See the [Sidekiq documentation
-about Redis](https://github.com/mperham/sidekiq/wiki/Using-Redis) for more
+latency and potentially cause client timeouts. See the 
+[Sidekiq documentation about Redis](https://github.com/mperham/sidekiq/wiki/Using-Redis) for more
 details.
 
 #### When running Sidekiq cluster (default)
diff --git a/doc/administration/operations/extra_sidekiq_routing.md b/doc/administration/operations/extra_sidekiq_routing.md
index 1b6ac5917d1..1193a5c110d 100644
--- a/doc/administration/operations/extra_sidekiq_routing.md
+++ b/doc/administration/operations/extra_sidekiq_routing.md
@@ -76,9 +76,9 @@ workers.
 ## Worker matching query
 
 GitLab provides a query syntax to match a worker based on its
-attributes. This query syntax is employed by both [Queue routing
-rules](#queue-routing-rules) and [Queue
-selector](extra_sidekiq_processes.md#queue-selector). A query includes two
+attributes. This query syntax is employed by both 
+[Queue routing rules](#queue-routing-rules) and 
+[Queue selector](extra_sidekiq_processes.md#queue-selector). A query includes two
 components:
 
 - Attributes that can be selected.
@@ -92,8 +92,8 @@ Queue matching query works upon the worker attributes, described in
 [Sidekiq style guide](../../development/sidekiq/index.md). We support querying
 based on a subset of worker attributes:
 
-- `feature_category` - the [GitLab feature
-  category](https://about.gitlab.com/direction/maturity/#category-maturity) the
+- `feature_category` - the 
+  [GitLab feature category](https://about.gitlab.com/direction/maturity/#category-maturity) the
   queue belongs to. For example, the `merge` queue belongs to the
   `source_code_management` category.
 - `has_external_dependencies` - whether or not the queue connects to external
@@ -122,10 +122,10 @@ that have tags `a`, `b`, or both. `tags!=a,b` selects queues that have
 neither of those tags.
 
 The attributes of each worker are hard-coded in the source code. For
-convenience, we generate a [list of all available attributes in
-GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/all_queues.yml)
-and a [list of all available attributes in
-GitLab Enterprise Edition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/workers/all_queues.yml).
+convenience, we generate a 
+[list of all available attributes in GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/all_queues.yml)
+and a 
+[list of all available attributes in GitLab Enterprise Edition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/workers/all_queues.yml).
 
 ### Available operators
 
@@ -160,8 +160,7 @@ entire queue group selects all queues.
 After the Sidekiq routing rules are changed, administrators must take care
 with the migration to avoid losing jobs entirely, especially in a system with
 long queues of jobs. The migration can be done by following the migration steps
-mentioned in [Sidekiq job
-migration](../../raketasks/sidekiq_job_migration.md)
+mentioned in [Sidekiq job migration](../../raketasks/sidekiq_job_migration.md)
 
 ### Workers that cannot be migrated
 
@@ -177,5 +176,5 @@ sidekiq['routing_rules'] = [
 ]
 ```
 
-These queues must also be included in at least one [Sidekiq
-queue group](extra_sidekiq_processes.md#start-multiple-processes).
+These queues must also be included in at least one 
+[Sidekiq queue group](extra_sidekiq_processes.md#start-multiple-processes).
diff --git a/doc/administration/operations/index.md b/doc/administration/operations/index.md
index 41a9a0e6d67..a6e66abdbdb 100644
--- a/doc/administration/operations/index.md
+++ b/doc/administration/operations/index.md
@@ -18,10 +18,9 @@ Keep your GitLab instance up and running smoothly.
 - [Multiple Sidekiq processes](extra_sidekiq_processes.md): Configure multiple Sidekiq processes to ensure certain queues always have dedicated workers, no matter the number of jobs that must be processed. **(FREE SELF)**
 - [Sidekiq routing rules](extra_sidekiq_routing.md): Configure the routing rules to route a job from a worker to a desirable queue. **(FREE SELF)**
 - [Puma](puma.md): Understand Puma and puma-worker-killer.
-- Speed up SSH operations by [Authorizing SSH users via a fast,
-  indexed lookup to the GitLab database](fast_ssh_key_lookup.md), and/or
-  by [doing away with user SSH keys stored on GitLab entirely in favor
-  of SSH certificates](ssh_certificates.md).
+- Speed up SSH operations by 
+  [Authorizing SSH users via a fast, indexed lookup to the GitLab database](fast_ssh_key_lookup.md), and/or
+  by [doing away with user SSH keys stored on GitLab entirely in favor of SSH certificates](ssh_certificates.md).
 - [File System Performance Benchmarking](filesystem_benchmarking.md): File system
   performance can have a big impact on GitLab performance, especially for actions
   that read or write Git repositories. This information helps benchmark
diff --git a/doc/administration/operations/rails_console.md b/doc/administration/operations/rails_console.md
index 660a99faaf8..430dfbc637c 100644
--- a/doc/administration/operations/rails_console.md
+++ b/doc/administration/operations/rails_console.md
@@ -6,8 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Rails console **(FREE SELF)**
 
-At the heart of GitLab is a web application [built using the Ruby on Rails
-framework](https://about.gitlab.com/blog/2018/10/29/why-we-use-rails-to-build-gitlab/).
+At the heart of GitLab is a web application 
+[built using the Ruby on Rails framework](https://about.gitlab.com/blog/2018/10/29/why-we-use-rails-to-build-gitlab/).
 The [Rails console](https://guides.rubyonrails.org/command_line.html#rails-console).
 provides a way to interact with your GitLab instance from the command line, and also grants access to the amazing tools built right into Rails.
 
@@ -19,8 +19,8 @@ with no consequences, you are strongly advised to do so in a test environment.
 
 The Rails console is for GitLab system administrators who are troubleshooting
 a problem or need to retrieve some data that can only be done through direct
-access of the GitLab application. Basic knowledge of Ruby is needed (try [this
-30-minute tutorial](https://try.ruby-lang.org/) for a quick introduction).
+access of the GitLab application. Basic knowledge of Ruby is needed (try 
+[this 30-minute tutorial](https://try.ruby-lang.org/) for a quick introduction).
 Rails experience is useful but not required.
 
 ## Starting a Rails console session
@@ -136,8 +136,8 @@ root
 1
 ```
 
-Some basic knowledge of Ruby will be very useful. Try [this
-30-minute tutorial](https://try.ruby-lang.org/) for a quick introduction.
+Some basic knowledge of Ruby will be very useful. Try 
+[this 30-minute tutorial](https://try.ruby-lang.org/) for a quick introduction.
 Rails experience is helpful but not essential.
 
 ### Troubleshooting Rails Runner
diff --git a/doc/administration/operations/sidekiq_memory_killer.md b/doc/administration/operations/sidekiq_memory_killer.md
index d9558c3d7a6..12381808523 100644
--- a/doc/administration/operations/sidekiq_memory_killer.md
+++ b/doc/administration/operations/sidekiq_memory_killer.md
@@ -57,8 +57,7 @@ The MemoryKiller is controlled using environment variables.
   the restart is aborted.
 
   The default value for Omnibus packages is set
-  [in the Omnibus GitLab
-  repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb).
+  [in the Omnibus GitLab repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb).
 
 - `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS` (KB): is used by _daemon_ mode. If the Sidekiq
   process RSS (expressed in kilobytes) exceeds `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS`,
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index 413c14aba94..1e405189342 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -35,10 +35,10 @@ uploading user SSH keys to GitLab entirely.
 ## Setting up SSH certificate lookup via GitLab Shell
 
 How to fully set up SSH certificates is outside the scope of this
-document. See [OpenSSH's
-`PROTOCOL.certkeys`](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)
-for how it works, for example [RedHat's documentation about
-it](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication).
+document. See
+[OpenSSH's`PROTOCOL.certkeys`](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)
+for how it works, for example
+[RedHat's documentation about it](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication).
 
 We assume that you already have SSH certificates set up, and have
 added the `TrustedUserCAKeys` of your CA to your `sshd_config`, for example:
@@ -159,8 +159,8 @@ users (especially if they're renewed) than you have deploy keys.
 Users can still bypass SSH certificate authentication by manually
 uploading an SSH public key to their profile, relying on the
 `~/.ssh/authorized_keys` fallback to authenticate it. There's
-currently no feature to prevent this, [but there's an open request for
-adding it](https://gitlab.com/gitlab-org/gitlab/-/issues/23260).
+currently no feature to prevent this, 
+[but there's an open request for adding it](https://gitlab.com/gitlab-org/gitlab/-/issues/23260).
 
 Such a restriction can currently be hacked in by, for example, providing a
 custom `AuthorizedKeysCommand` which checks if the discovered key-ID
diff --git a/doc/administration/package_information/postgresql_versions.md b/doc/administration/package_information/postgresql_versions.md
index e208f9dc935..d831e8cea7f 100644
--- a/doc/administration/package_information/postgresql_versions.md
+++ b/doc/administration/package_information/postgresql_versions.md
@@ -20,8 +20,7 @@ For example:
 - Omnibus 12.7.6 shipped with PostgreSQL 9.6.14 and 10.9.
 - Omnibus 12.7.7 shipped with PostgreSQL 9.6.17 and 10.12.
 
-[Find out which versions of PostgreSQL (and other components) ship with
-each Omnibus GitLab release](https://gitlab-org.gitlab.io/omnibus-gitlab/licenses.html).
+[Find out which versions of PostgreSQL (and other components) ship with each Omnibus GitLab release](https://gitlab-org.gitlab.io/omnibus-gitlab/licenses.html).
 
 The lowest supported PostgreSQL versions are listed in the
 [installation requirements](../../install/requirements.md#postgresql-requirements).
diff --git a/doc/administration/package_information/supported_os.md b/doc/administration/package_information/supported_os.md
index 739ba80ea2b..7f79aa72a02 100644
--- a/doc/administration/package_information/supported_os.md
+++ b/doc/administration/package_information/supported_os.md
@@ -10,8 +10,8 @@ GitLab officially supports LTS versions of operating systems. While OSs like
 Ubuntu have a clear distinction between LTS and non-LTS versions, there are
 other OSs, openSUSE for example, that don't follow the LTS concept. Hence to
 avoid confusion, the official policy is that at any point of time, all the
-operating systems supported by GitLab are listed in the [installation
-page](https://about.gitlab.com/install/).
+operating systems supported by GitLab are listed in the 
+[installation page](https://about.gitlab.com/install/).
 
 The following lists the currently supported OSs and their possible EOL dates.
 
diff --git a/doc/administration/redis/replication_and_failover.md b/doc/administration/redis/replication_and_failover.md
index 5132ffd9b5d..c4b83b66738 100644
--- a/doc/administration/redis/replication_and_failover.md
+++ b/doc/administration/redis/replication_and_failover.md
@@ -343,8 +343,8 @@ NOTE:
 If you are using an external Redis Sentinel instance, be sure
 to exclude the `requirepass` parameter from the Sentinel
 configuration. This parameter causes clients to report `NOAUTH
-Authentication required.`. [Redis Sentinel 3.2.x does not support
-password authentication](https://github.com/antirez/redis/issues/3279).
+Authentication required.`. 
+[Redis Sentinel 3.2.x does not support password authentication](https://github.com/antirez/redis/issues/3279).
 
 Now that the Redis servers are all set up, let's configure the Sentinel
 servers.
diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md
index 6ac031ea6bd..6625039504a 100644
--- a/doc/administration/restart_gitlab.md
+++ b/doc/administration/restart_gitlab.md
@@ -102,8 +102,8 @@ depend on those files.
 
 ## Installations from source
 
-If you have followed the official installation guide to [install GitLab from
-source](../install/installation.md), run the following command to restart GitLab:
+If you have followed the official installation guide to 
+[install GitLab from source](../install/installation.md), run the following command to restart GitLab:
 
 ```shell
 # For systems running systemd
diff --git a/doc/administration/terraform_state.md b/doc/administration/terraform_state.md
index 14649b82ba8..7a8d7774948 100644
--- a/doc/administration/terraform_state.md
+++ b/doc/administration/terraform_state.md
@@ -78,9 +78,9 @@ Terraform state files are stored locally, follow the steps below.
 
 ## Using object storage **(FREE SELF)**
 
-Instead of storing Terraform state files on disk, we recommend the use of [one of the supported object
-storage options](object_storage.md#options). This configuration relies on valid credentials to
-be configured already.
+Instead of storing Terraform state files on disk, we recommend the use of 
+[one of the supported object storage options](object_storage.md#options). 
+This configuration relies on valid credentials to be configured already.
 
 [Read more about using object storage with GitLab](object_storage.md).
 
diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md
index ab33deda687..12704f6fc87 100644
--- a/doc/api/oauth2.md
+++ b/doc/api/oauth2.md
@@ -261,8 +261,8 @@ Check the [RFC spec](https://tools.ietf.org/html/rfc6749#section-4.3) for a
 detailed flow description.
 
 NOTE:
-The Resource Owner Password Credentials is disabled for users with [two-factor
-authentication](../user/profile/account/two_factor_authentication.md) turned on.
+The Resource Owner Password Credentials is disabled for users with 
+[two-factor authentication](../user/profile/account/two_factor_authentication.md) turned on.
 These users can access the API using [personal access tokens](../user/profile/personal_access_tokens.md)
 instead.
 
diff --git a/doc/architecture/blueprints/ci_data_decay/index.md b/doc/architecture/blueprints/ci_data_decay/index.md
index 8808a526df0..7c0bdf299db 100644
--- a/doc/architecture/blueprints/ci_data_decay/index.md
+++ b/doc/architecture/blueprints/ci_data_decay/index.md
@@ -48,8 +48,8 @@ PostgreSQL database running on GitLab.com.
 This volume contributes to significant performance problems, development
 challenges and is often related to production incidents.
 
-We also expect a [significant growth in the number of builds executed on
-GitLab.com](../ci_scale/index.md) in the upcoming years.
+We also expect a [significant growth in the number of builds executed on GitLab.com](../ci_scale/index.md) 
+in the upcoming years.
 
 ## Opportunity
 
@@ -61,8 +61,8 @@ pipelines that are older than a few months might help us to move this data out
 of the primary database, to a different storage, that is more performant and
 cost effective.
 
-It is already possible to prevent processing builds [that have been
-archived](../../../user/admin_area/settings/continuous_integration.md#archive-jobs).
+It is already possible to prevent processing builds 
+[that have been archived](../../../user/admin_area/settings/continuous_integration.md#archive-jobs).
 When a build gets archived it will not be possible to retry it, but we still do
 keep all the processing metadata in the database, and it consumes resources
 that are scarce in the primary database.
diff --git a/doc/architecture/blueprints/ci_scale/index.md b/doc/architecture/blueprints/ci_scale/index.md
index 40318f19286..5822ae2b5ed 100644
--- a/doc/architecture/blueprints/ci_scale/index.md
+++ b/doc/architecture/blueprints/ci_scale/index.md
@@ -89,8 +89,8 @@ environment.
 
 We also expect a significant, exponential growth in the upcoming years.
 
-One of the forecasts done using [Facebook's
-Prophet](https://facebook.github.io/prophet/) shows that in the first half of
+One of the forecasts done using [Facebook's Prophet](https://facebook.github.io/prophet/)
+shows that in the first half of
 2024 we expect seeing 20M builds created on GitLab.com each day. In comparison
 to around 2M we see created today, this is 10x growth our product might need to
 sustain in upcoming years.
@@ -115,17 +115,14 @@ of the CI/CD Apdex score, and sometimes even causes a significant performance
 degradation in the production environment.
 
 There are multiple other strategies that can improve performance and
-reliability. We can use [Redis
-queuing](https://gitlab.com/gitlab-org/gitlab/-/issues/322972), or [a separate
-table that will accelerate SQL queries used to build
-queues](https://gitlab.com/gitlab-org/gitlab/-/issues/322766) and we want to
-explore them.
-
-**Status**: As of October 2021 the new architecture [has been implemented on
-GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/5909#note_680407908).
-The following epic tracks making it generally available: [Make the new pending
-builds architecture generally available](
-https://gitlab.com/groups/gitlab-org/-/epics/6954).
+reliability. We can use [Redis queuing](https://gitlab.com/gitlab-org/gitlab/-/issues/322972), or 
+[a separate table that will accelerate SQL queries used to build queues](https://gitlab.com/gitlab-org/gitlab/-/issues/322766)
+and we want to explore them.
+
+**Status**: As of October 2021 the new architecture 
+[has been implemented on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/5909#note_680407908).
+The following epic tracks making it generally available: 
+[Make the new pending builds architecture generally available](https://gitlab.com/groups/gitlab-org/-/epics/6954).
 
 ### Moving big amounts of data is challenging
 
diff --git a/doc/architecture/blueprints/cloud_native_build_logs/index.md b/doc/architecture/blueprints/cloud_native_build_logs/index.md
index 3aba10fc758..0c941e332cb 100644
--- a/doc/architecture/blueprints/cloud_native_build_logs/index.md
+++ b/doc/architecture/blueprints/cloud_native_build_logs/index.md
@@ -12,8 +12,8 @@ Cloud native and the adoption of Kubernetes has been recognised by GitLab to be
 one of the top two biggest tailwinds that are helping us grow faster as a
 company behind the project.
 
-This effort is described in a more details [in the infrastructure team
-handbook](https://about.gitlab.com/handbook/engineering/infrastructure/production/kubernetes/gitlab-com/).
+This effort is described in a more details 
+[in the infrastructure team handbook](https://about.gitlab.com/handbook/engineering/infrastructure/production/kubernetes/gitlab-com/).
 
 ## Traditional build logs
 
@@ -88,9 +88,8 @@ even tried to replace NFS with
 
 Since that time it has become apparent that the cost of operations and
 maintenance of a NFS cluster is significant and that if we ever decide to
-migrate to Kubernetes [we need to decouple GitLab from a shared local storage
-and
-NFS](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/426#note_375646396).
+migrate to Kubernetes 
+[we need to decouple GitLab from a shared local storage and NFS](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/426#note_375646396).
 
 1. NFS might be a single point of failure
 1. NFS can only be reliably scaled vertically
@@ -112,12 +111,10 @@ of complexity, maintenance cost and enormous, negative impact on availability.
 1. ✓ Rollout the feature into production environment incrementally
 
 The work needed to make the new architecture production ready and enabled on
-GitLab.com had been tracked in [Cloud Native Build Logs on
-GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/4275) epic.
+GitLab.com had been tracked in [Cloud Native Build Logs on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/4275) epic.
 
-Enabling this feature on GitLab.com is a subtask of [making the new
-architecture generally
-available](https://gitlab.com/groups/gitlab-org/-/epics/3791) for everyone.
+Enabling this feature on GitLab.com is a subtask of 
+[making the new architecture generally available](https://gitlab.com/groups/gitlab-org/-/epics/3791) for everyone.
 
 ## Status
 
diff --git a/doc/architecture/blueprints/cloud_native_gitlab_pages/index.md b/doc/architecture/blueprints/cloud_native_gitlab_pages/index.md
index e545e8844ec..89c3a4cd6b4 100644
--- a/doc/architecture/blueprints/cloud_native_gitlab_pages/index.md
+++ b/doc/architecture/blueprints/cloud_native_gitlab_pages/index.md
@@ -17,8 +17,8 @@ Cloud Native and the adoption of Kubernetes has been recognised by GitLab to be
 one of the top two biggest tailwinds that are helping us grow faster as a
 company behind the project.
 
-This effort is described in more detail [in the infrastructure team handbook
-page](https://about.gitlab.com/handbook/engineering/infrastructure/production/kubernetes/gitlab-com/).
+This effort is described in more detail 
+[in the infrastructure team handbook page](https://about.gitlab.com/handbook/engineering/infrastructure/production/kubernetes/gitlab-com/).
 
 GitLab Pages is tightly coupled with NFS and in order to unblock Kubernetes
 migration a significant change to GitLab Pages' architecture is required. This
@@ -55,9 +55,8 @@ even tried to replace NFS with
 
 Since that time it has become apparent that the cost of operations and
 maintenance of a NFS cluster is significant and that if we ever decide to
-migrate to Kubernetes [we need to decouple GitLab from a shared local storage
-and
-NFS](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/426#note_375646396).
+migrate to Kubernetes 
+[we need to decouple GitLab from a shared local storage and NFS](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/426#note_375646396).
 
 1. NFS might be a single point of failure
 1. NFS can only be reliably scaled vertically
@@ -84,8 +83,8 @@ graph TD
   C -- Serves static content --> E(Visitors)
 ```
 
-This new architecture has been briefly described in [the blog
-post](https://about.gitlab.com/blog/2020/08/03/how-gitlab-pages-uses-the-gitlab-api-to-serve-content/)
+This new architecture has been briefly described in 
+[the blog post](https://about.gitlab.com/blog/2020/08/03/how-gitlab-pages-uses-the-gitlab-api-to-serve-content/)
 too.
 
 ## Iterations
diff --git a/doc/architecture/blueprints/feature_flags_development/index.md b/doc/architecture/blueprints/feature_flags_development/index.md
index 94d52ea3474..eaca7da6bd7 100644
--- a/doc/architecture/blueprints/feature_flags_development/index.md
+++ b/doc/architecture/blueprints/feature_flags_development/index.md
@@ -115,9 +115,9 @@ These are reason why these changes are needed:
 
 ## Iterations
 
-This work is being done as part of dedicated epic: [Improve internal usage of
-Feature Flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). This epic
-describes a meta reasons for making these changes.
+This work is being done as part of dedicated epic: 
+[Improve internal usage of Feature Flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). 
+This epic describes a meta reasons for making these changes.
 
 ## Who
 
diff --git a/doc/architecture/blueprints/graphql_api/index.md b/doc/architecture/blueprints/graphql_api/index.md
index 2dfd83dc6e4..eb045de491e 100644
--- a/doc/architecture/blueprints/graphql_api/index.md
+++ b/doc/architecture/blueprints/graphql_api/index.md
@@ -44,12 +44,12 @@ It is an opportunity to learn from our experience in evolving the REST API, for
 the scale, and to apply this knowledge onto the GraphQL development efforts. We
 can do that by building query-to-feature correlation mechanisms, adding
 scalable state synchronization support and aligning GraphQL with other
-architectural initiatives being executed in parallel, like [the support for
-direct uploads](https://gitlab.com/gitlab-org/gitlab/-/issues/280819).
+architectural initiatives being executed in parallel, like 
+[the support for direct uploads](https://gitlab.com/gitlab-org/gitlab/-/issues/280819).
 
 GraphQL should be secure by default. We can avoid common security mistakes by
-building mechanisms that will help us to enforce [OWASP GraphQL
-recommendations](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html)
+building mechanisms that will help us to enforce 
+[OWASP GraphQL recommendations](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html)
 that are relevant to us.
 
 Understanding what are the needs of the wider community will also allow us to
diff --git a/doc/architecture/blueprints/object_storage/index.md b/doc/architecture/blueprints/object_storage/index.md
index 3420caa325f..b70339c8b8d 100644
--- a/doc/architecture/blueprints/object_storage/index.md
+++ b/doc/architecture/blueprints/object_storage/index.md
@@ -31,9 +31,9 @@ underlying implementation for shared, distributed, highly-available
 (HA) file storage.
 
 Over time, we have built support for object storage across the
-application, solving specific problems in a [multitude of
-iterations](https://about.gitlab.com/company/team/structure/working-groups/object-storage/#company-efforts-on-uploads). This
-has led to increased complexity across the board, from development
+application, solving specific problems in a 
+[multitude of iterations](https://about.gitlab.com/company/team/structure/working-groups/object-storage/#company-efforts-on-uploads). 
+This has led to increased complexity across the board, from development
 (new features and bug fixes) to installation:
 
 - New GitLab installations require the creation and configuration of
@@ -67,10 +67,8 @@ has led to increased complexity across the board, from development
 The following is a brief description of the main directions we can take to
 remove the pain points affecting our object storage implementation.
 
-This is also available as [a YouTube
-video](https://youtu.be/X9V_w8hsM8E) recorded for the [Object Storage
-Working
-Group](https://about.gitlab.com/company/team/structure/working-groups/object-storage/).
+This is also available as [a YouTube video](https://youtu.be/X9V_w8hsM8E) recorded for the 
+[Object Storage Working Group](https://about.gitlab.com/company/team/structure/working-groups/object-storage/).
 
 ### Simplify GitLab architecture by shipping MinIO
 
@@ -80,8 +78,8 @@ local storage and object storage.
 
 With local storage, there is the assumption of a shared storage
 between components. This can be achieved by having a single box
-installation, without HA, or with a NFS, which [we no longer
-recommend](../../../administration/nfs.md).
+installation, without HA, or with a NFS, which 
+[we no longer recommend](../../../administration/nfs.md).
 
 We have a testing gap on object storage. It also requires Workhorse
 and MinIO, which are not present in our pipelines, so too much is
@@ -136,8 +134,8 @@ access to new features without infrastructure chores.
 
 Our implementation is built on top of a 3rd-party framework where
 every object storage client is a 3rd-party library. Unfortunately some
-of them are unmaintained. [We have customers who cannot push 5GB Git
-LFS objects](https://gitlab.com/gitlab-org/gitlab/-/issues/216442),
+of them are unmaintained. 
+[We have customers who cannot push 5GB Git LFS objects](https://gitlab.com/gitlab-org/gitlab/-/issues/216442),
 but with such a vital feature implemented in 3rd-party libraries we
 are slowed down in fixing it, and we also rely on external maintainers
 to merge and release fixes.
@@ -147,8 +145,7 @@ Before the introduction of direct upload, using the
 library, _"a gem that provides a simple and extremely flexible way to
 upload files from Ruby applications."_, was the boring solution.
 However this is no longer our use-case, as we upload files from
-Workhorse, and we had to [patch CarrierWave's
-internals](https://gitlab.com/gitlab-org/gitlab/-/issues/285597#note_452696638)
+Workhorse, and we had to [patch CarrierWave's internals](https://gitlab.com/gitlab-org/gitlab/-/issues/285597#note_452696638)
 to support direct upload.
 
 A brief proposal covering CarrierWave removal and a new streamlined
@@ -217,7 +214,7 @@ Proposal:
 
 DRIs:
 
-The DRI for this blueprint is the [Object Storage Working
-Group](https://about.gitlab.com/company/team/structure/working-groups/object-storage/).
+The DRI for this blueprint is the 
+[Object Storage Working Group](https://about.gitlab.com/company/team/structure/working-groups/object-storage/).
 
 <!-- vale gitlab.Spelling = YES -->
diff --git a/doc/architecture/blueprints/runner_scaling/index.md b/doc/architecture/blueprints/runner_scaling/index.md
index c4bd8433ab3..494aaa6a641 100644
--- a/doc/architecture/blueprints/runner_scaling/index.md
+++ b/doc/architecture/blueprints/runner_scaling/index.md
@@ -33,8 +33,8 @@ This design choice was crucial for the GitLab Runner success. Since that time
 the auto-scaling feature has been used by many users and customers and enabled
 rapid growth of CI/CD adoption on GitLab.com.
 
-We can not, however, continue using Docker Machine. Work on that project [was
-paused in July 2018](https://github.com/docker/machine/issues/4537) and there
+We can not, however, continue using Docker Machine. Work on that project 
+[was paused in July 2018](https://github.com/docker/machine/issues/4537) and there
 was no development made since that time (except for some highly important
 security fixes). In 2018, after Docker Machine entered the "maintenance mode",
 we decided to create [our own fork](https://gitlab.com/gitlab-org/ci-cd/docker-machine)
@@ -76,8 +76,8 @@ mechanism with a reliable and flexible mechanism. We might be unable to build a
 drop-in replacement for Docker Machine, as there are presumably many reasons
 why it has been deprecated. It is very difficult to maintain compatibility with
 so many cloud providers, and it seems that Docker Machine has been deprecated
-in favor of Docker Desktop, which is not a viable replacement for us. [This
-issue](https://github.com/docker/roadmap/issues/245) contains a discussion
+in favor of Docker Desktop, which is not a viable replacement for us. 
+[This issue](https://github.com/docker/roadmap/issues/245) contains a discussion
 about how people are using Docker Machine right now, and it seems that GitLab
 CI is one of the most frequent reasons for people to keep using Docker Machine.
 
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
index cae03ee6185..00025a66936 100644
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
+++ b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
@@ -233,6 +233,7 @@ The following job, when run for the default branch, is able to read secrets unde
 
 ```yaml
 read_secrets:
+  image: vault:latest
   script:
     # Check job's ref name
     - echo $CI_COMMIT_REF_NAME
@@ -261,6 +262,7 @@ The following job is able to authenticate using the `myproject-production` role
 
 ```yaml
 read_secrets:
+  image: vault:latest
   script:
     # Check job's ref name
     - echo $CI_COMMIT_REF_NAME
diff --git a/doc/ci/interactive_web_terminal/index.md b/doc/ci/interactive_web_terminal/index.md
index f49fdd6c39f..e6a9f1fa646 100644
--- a/doc/ci/interactive_web_terminal/index.md
+++ b/doc/ci/interactive_web_terminal/index.md
@@ -18,8 +18,8 @@ taken to protect the users.
 
 NOTE:
 [Shared runners on GitLab.com](../runners/index.md) do not
-provide an interactive web terminal. Follow [this
-issue](https://gitlab.com/gitlab-org/gitlab/-/issues/24674) for progress on
+provide an interactive web terminal. Follow 
+[this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/24674) for progress on
 adding support. For groups and projects hosted on GitLab.com, interactive web
 terminals are available when using your own group or project runner.
 
@@ -27,8 +27,8 @@ terminals are available when using your own group or project runner.
 
 Two things need to be configured for the interactive web terminal to work:
 
-- The runner needs to have [`[session_server]` configured
-  properly](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section)
+- The runner needs to have 
+  [`[session_server]` configured properly](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section)
 - If you are using a reverse proxy with your GitLab instance, web terminals need to be
   [enabled](../../administration/integration/terminal.md#enabling-and-disabling-terminal-support)
 
@@ -54,8 +54,8 @@ Not all executors are
 NOTE:
 The `docker` executor does not keep running
 after the build script is finished. At that point, the terminal automatically
-disconnects and does not wait for the user to finish. Please follow [this
-issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3605) for updates on
+disconnects and does not wait for the user to finish. Please follow 
+[this issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3605) for updates on
 improving this behavior.
 
 Sometimes, when a job is running, things don't go as you would expect, and it
@@ -63,8 +63,7 @@ would be helpful if one can have a shell to aid debugging. When a job is
 running, on the right panel you can see a button `debug` that opens the terminal
 for the current job.
 
-![Example of job running with terminal
-available](img/interactive_web_terminal_running_job.png)
+![Example of job running with terminal available](img/interactive_web_terminal_running_job.png)
 
 When clicked, a new tab opens to the terminal page where you can access
 the terminal and type commands like a normal shell.
diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md
index f3044a03e04..3904a527a8f 100644
--- a/doc/ci/large_repositories/index.md
+++ b/doc/ci/large_repositories/index.md
@@ -116,8 +116,7 @@ you could add [`--no-tags`](https://git-scm.com/docs/git-fetch#Documentation/git
 to the extra flags to make your fetches faster and more compact.
 
 Also in the case where you repository does _not_ contain a lot of
-tags, `--no-tags` can [make a big difference in some
-cases](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/746).
+tags, `--no-tags` can [make a big difference in some cases](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/746).
 If your CI builds do not depend on Git tags it is worth trying.
 
 See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/configure_runners.md#git-fetch-extra-flags)
diff --git a/doc/ci/runners/runners_scope.md b/doc/ci/runners/runners_scope.md
index 8b2753d26f1..186d874338c 100644
--- a/doc/ci/runners/runners_scope.md
+++ b/doc/ci/runners/runners_scope.md
@@ -28,8 +28,8 @@ If you are using a self-managed instance of GitLab:
   going to your project's **Settings > CI/CD**, expanding the **Runners** section,
   and clicking **Show runner installation instructions**.
   These instructions are also available [in the documentation](https://docs.gitlab.com/runner/install/index.html).
-- The administrator can also configure a maximum number of shared runner [CI/CD minutes for
-  each group](../pipelines/cicd_minutes.md#set-the-quota-of-cicd-minutes-for-a-specific-namespace).
+- The administrator can also configure a maximum number of shared runner 
+  [CI/CD minutes for each group](../pipelines/cicd_minutes.md#set-the-quota-of-cicd-minutes-for-a-specific-namespace).
 
 If you are using GitLab.com:
 
diff --git a/doc/ci/runners/saas/windows_saas_runner.md b/doc/ci/runners/saas/windows_saas_runner.md
index dddb3afee7c..f9fe6290220 100644
--- a/doc/ci/runners/saas/windows_saas_runner.md
+++ b/doc/ci/runners/saas/windows_saas_runner.md
@@ -126,8 +126,7 @@ test:
 
 ## Limitations and known issues
 
-- All the limitations mentioned in our [beta
-  definition](../../../policy/alpha-beta-support.md#beta-features).
+- All the limitations mentioned in our [beta definition](../../../policy/alpha-beta-support.md#beta-features).
 - The average provisioning time for a new Windows VM is 5 minutes.
   This means that you may notice slower build start times
   on the Windows runner fleet during the beta. In a future
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index 0c8c8b24b3b..ddc7aae6f4d 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -246,8 +246,7 @@ end
 NOTE:
 For specifics on implementation, see [Pagination implementation](#pagination-implementation).
 
-GraphQL uses [cursor based
-pagination](https://graphql.org/learn/pagination/#pagination-and-edges)
+GraphQL uses [cursor based pagination](https://graphql.org/learn/pagination/#pagination-and-edges)
 to expose collections of items. This provides the clients with a lot
 of flexibility while also allowing the backend to use different
 pagination models.
@@ -1608,8 +1607,8 @@ correctly rendered to the clients.
 
 ### Errors in mutations
 
-We encourage following the practice of [errors as
-data](https://graphql-ruby.org/mutations/mutation_errors) for mutations, which
+We encourage following the practice of 
+[errors as data](https://graphql-ruby.org/mutations/mutation_errors) for mutations, which
 distinguishes errors by who they are relevant to, defined by who can deal with
 them.
 
diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index f28250b6057..b72ef1bffc4 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -110,15 +110,15 @@ Model.create(foo: params[:foo])
 
 With Grape v1.3+, Array types must be defined with a `coerce_with`
 block, or parameters, fails to validate when passed a string from an
-API request. See the [Grape upgrading
-documentation](https://github.com/ruby-grape/grape/blob/master/UPGRADING.md#ensure-that-array-types-have-explicit-coercions)
+API request. See the 
+[Grape upgrading documentation](https://github.com/ruby-grape/grape/blob/master/UPGRADING.md#ensure-that-array-types-have-explicit-coercions)
 for more details.
 
 ### Automatic coercion of nil inputs
 
 Prior to Grape v1.3.3, Array parameters with `nil` values would
-automatically be coerced to an empty Array. However, due to [this pull
-request in v1.3.3](https://github.com/ruby-grape/grape/pull/2040), this
+automatically be coerced to an empty Array. However, due to 
+[this pull request in v1.3.3](https://github.com/ruby-grape/grape/pull/2040), this
 is no longer the case. For example, suppose you define a PUT `/test`
 request that has an optional parameter:
 
@@ -259,8 +259,8 @@ In situations where the same model has multiple entities in the API
 discretion with applying this scope. It may be that you optimize for the
 most basic entity, with successive entities building upon that scope.
 
-The `with_api_entity_associations` scope also [automatically preloads
-data](https://gitlab.com/gitlab-org/gitlab/-/blob/19f74903240e209736c7668132e6a5a735954e7c/app%2Fmodels%2Ftodo.rb#L34)
+The `with_api_entity_associations` scope also 
+[automatically preloads data](https://gitlab.com/gitlab-org/gitlab/-/blob/19f74903240e209736c7668132e6a5a735954e7c/app%2Fmodels%2Ftodo.rb#L34)
 for `Todo` _targets_ when returned in the [to-dos API](../api/todos.md).
 
 For more context and discussion about preloading see
diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md
index 2826b8a3bc4..ceb3c124d1a 100644
--- a/doc/development/application_limits.md
+++ b/doc/development/application_limits.md
@@ -15,8 +15,7 @@ First of all, you have to gather information and decide which are the different
 limits that are set for the different GitLab tiers. Coordinate with others to [document](../administration/instance_limits.md)
 and communicate those limits.
 
-There is a guide about [introducing application
-limits](https://about.gitlab.com/handbook/product/product-processes/#introducing-application-limits).
+There is a guide about [introducing application limits](https://about.gitlab.com/handbook/product/product-processes/#introducing-application-limits).
 
 ## Implement plan limits
 
diff --git a/doc/development/auto_devops.md b/doc/development/auto_devops.md
index 2989e10a124..55ab234cc68 100644
--- a/doc/development/auto_devops.md
+++ b/doc/development/auto_devops.md
@@ -20,8 +20,8 @@ based on your project contents. When Auto DevOps is enabled for a
 project, the user does not need to explicitly include any pipeline configuration
 through a [`.gitlab-ci.yml` file](../ci/yaml/index.md).
 
-In the absence of a `.gitlab-ci.yml` file, the [Auto DevOps CI
-template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
+In the absence of a `.gitlab-ci.yml` file, the 
+[Auto DevOps CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
 is used implicitly to configure the pipeline for the project. This
 template is a top-level template that includes other sub-templates,
 which then defines jobs.
diff --git a/doc/development/build_test_package.md b/doc/development/build_test_package.md
index 89b13efc1aa..4645bd02d9e 100644
--- a/doc/development/build_test_package.md
+++ b/doc/development/build_test_package.md
@@ -13,8 +13,8 @@ pipeline that can be used to trigger a pipeline in the Omnibus GitLab repository
 that will create:
 
 - A deb package for Ubuntu 16.04, available as a build artifact, and
-- A Docker image, which is pushed to the [Omnibus GitLab container
-  registry](https://gitlab.com/gitlab-org/omnibus-gitlab/container_registry)
+- A Docker image, which is pushed to the 
+  [Omnibus GitLab container registry](https://gitlab.com/gitlab-org/omnibus-gitlab/container_registry)
   (images titled `gitlab-ce` and `gitlab-ee` respectively and image tag is the
   commit which triggered the pipeline).
 
diff --git a/doc/development/changelog.md b/doc/development/changelog.md
index 83919bab671..c5b234069e3 100644
--- a/doc/development/changelog.md
+++ b/doc/development/changelog.md
@@ -190,8 +190,8 @@ editor. Once closed, Git presents you with a new text editor instance to edit
 the commit message of commit B. Add the trailer, then save and quit the editor.
 If all went well, commit B is now updated.
 
-For more information about interactive rebases, take a look at [the Git
-documentation](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History).
+For more information about interactive rebases, take a look at 
+[the Git documentation](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History).
 
 ---
 
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 4175f68e7b6..de20bcdc059 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -487,16 +487,14 @@ Before taking the decision to merge:
 - If the MR contains both Quality and non-Quality-related changes, the MR should be merged by the relevant maintainer for user-facing changes (backend, frontend, or database) after the Quality related changes are approved by a Software Engineer in Test.
 
 If a merge request is fundamentally ready, but needs only trivial fixes (such as
-typos), consider demonstrating a [bias for
-action](https://about.gitlab.com/handbook/values/#bias-for-action) by making
-those changes directly without going back to the author. You can do this by
+typos), consider demonstrating a [bias for action](https://about.gitlab.com/handbook/values/#bias-for-action) 
+by making those changes directly without going back to the author. You can do this by
 using the [suggest changes](../user/project/merge_requests/reviews/suggestions.md) feature to apply
 your own suggestions to the merge request. Note that:
 
 - If the changes are not straightforward, please prefer allowing the author to make the change.
 - **Before applying suggestions**, edit the merge request to make sure
-  [squash and
-  merge](../user/project/merge_requests/squash_and_merge.md#squash-and-merge)
+  [squash and merge](../user/project/merge_requests/squash_and_merge.md#squash-and-merge)
   is enabled, otherwise, the pipeline's Danger job fails.
   - If a merge request does not have squash and merge enabled, and it
     has more than one commit, then see the note below about rewriting
@@ -511,8 +509,7 @@ When ready to merge:
 WARNING:
 **If the merge request is from a fork, also check the [additional guidelines for community contributions](#community-contributions).**
 
-- Consider using the [Squash and
-  merge](../user/project/merge_requests/squash_and_merge.md#squash-and-merge)
+- Consider using the [Squash and merge](../user/project/merge_requests/squash_and_merge.md#squash-and-merge)
   feature when the merge request has a lot of commits.
   When merging code, a maintainer should only use the squash feature if the
   author has already set this option, or if the merge request clearly contains a
@@ -532,8 +529,7 @@ WARNING:
     enough to `main`.
 - When you set the MR to "Merge When Pipeline Succeeds", you should take over
   subsequent revisions for anything that would be spotted after that.
-- For merge requests that have had [Squash and
-  merge](../user/project/merge_requests/squash_and_merge.md#squash-and-merge) set,
+- For merge requests that have had [Squash and merge](../user/project/merge_requests/squash_and_merge.md#squash-and-merge) set,
   the squashed commit's default commit message is taken from the merge request title.
   You're encouraged to [select a commit with a more informative commit message](../user/project/merge_requests/squash_and_merge.md) before merging.
 
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 2c3556e4fe2..faa1642d50a 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -319,8 +319,8 @@ request:
 We allow engineering time to fix small problems (with or without an
 issue) that are incremental improvements, such as:
 
-1. Unprioritized bug fixes (for example, [Banner alerting of project move is
-showing up everywhere](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18985))
+1. Unprioritized bug fixes (for example,
+   [Banner alerting of project move is showing up everywhere](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18985))
 1. Documentation improvements
 1. RuboCop or Code Quality improvements
 
diff --git a/doc/development/database/multiple_databases.md b/doc/development/database/multiple_databases.md
index 898a5b86007..31fc454f8a7 100644
--- a/doc/development/database/multiple_databases.md
+++ b/doc/development/database/multiple_databases.md
@@ -7,9 +7,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Multiple Databases
 
 To allow GitLab to scale further we
-[decomposed the GitLab application database into multiple
-databases](https://gitlab.com/groups/gitlab-org/-/epics/6168). The two databases
-are `main` and `ci`. GitLab supports being run with either one database or two databases.
+[decomposed the GitLab application database into multiple databases](https://gitlab.com/groups/gitlab-org/-/epics/6168). 
+The two databases are `main` and `ci`. GitLab supports being run with either one database or two databases.
 On GitLab.com we are using two separate databases.
 
 ## GitLab Schema
diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md
index 1e1ba45bd2a..d11bea86698 100644
--- a/doc/development/documentation/site_architecture/index.md
+++ b/doc/development/documentation/site_architecture/index.md
@@ -269,5 +269,5 @@ For more information, read about the [monthly release process](https://gitlab.co
 
 ## Review Apps for documentation merge requests
 
-If you are contributing to GitLab docs read how to [create a Review App with each
-merge request](../index.md#previewing-the-changes-live).
+If you are contributing to GitLab docs read how to 
+[create a Review App with each merge request](../index.md#previewing-the-changes-live).
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index 9bf3b56a72a..777bc77875e 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -281,8 +281,8 @@ There are a few gotchas with it:
   overriding the method, because we can't know when the overridden method
   (that is, calling `super` in the overriding method) would want to stop early.
   In this case, we shouldn't just override it, but update the original method
-  to make it call the other method we want to extend, like a [template method
-  pattern](https://en.wikipedia.org/wiki/Template_method_pattern).
+  to make it call the other method we want to extend, like a 
+  [template method pattern](https://en.wikipedia.org/wiki/Template_method_pattern).
   For example, given this base:
 
   ```ruby
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md
index 06623b7c707..47942817790 100644
--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
@@ -277,8 +277,8 @@ These Advanced Search migrations, like any other GitLab changes, need to support
 
 Depending on the order of deployment, it's possible that the migration
 has started or finished and there's still a server running the application code from before the
-migration. We need to take this into consideration until we can [ensure all Advanced Search migrations
-start after the deployment has finished](https://gitlab.com/gitlab-org/gitlab/-/issues/321619).
+migration. We need to take this into consideration until we can 
+[ensure all Advanced Search migrations start after the deployment has finished](https://gitlab.com/gitlab-org/gitlab/-/issues/321619).
 
 ### Reverting a migration
 
@@ -317,9 +317,8 @@ safely can.
 
 We choose to use GitLab major version upgrades as a safe time to remove
 backwards compatibility for indices that have not been fully migrated. We
-[document this in our upgrade
-documentation](../update/index.md#upgrading-to-a-new-major-version). We also
-choose to replace the migration code with the halted migration
+[document this in our upgrade documentation](../update/index.md#upgrading-to-a-new-major-version). 
+We also choose to replace the migration code with the halted migration
 and remove tests so that:
 
 - We don't need to maintain any code that is called from our Advanced Search
@@ -400,16 +399,15 @@ that may contain information to help diagnose performance issues.
 
 ### Performance Bar
 
-Elasticsearch requests will be displayed in the [`Performance
-Bar`](../administration/monitoring/performance/performance_bar.md), which can
+Elasticsearch requests will be displayed in the 
+[`Performance Bar`](../administration/monitoring/performance/performance_bar.md), which can
 be used both locally in development and on any deployed GitLab instance to
 diagnose poor search performance. This will show the exact queries being made,
 which is useful to diagnose why a search might be slow.
 
 ### Correlation ID and `X-Opaque-Id`
 
-Our [correlation
-ID](distributed_tracing.md#developer-guidelines-for-working-with-correlation-ids)
+Our [correlation ID](distributed_tracing.md#developer-guidelines-for-working-with-correlation-ids)
 is forwarded by all requests from Rails to Elasticsearch as the
 [`X-Opaque-Id`](https://www.elastic.co/guide/en/elasticsearch/reference/current/tasks.html#_identifying_running_tasks)
 header which allows us to track any
@@ -497,8 +495,8 @@ theoretically be used to figure out what needs to be replayed are:
    These updates can be replayed by triggering another
    `ElasticDeleteProjectWorker`.
 
-With the above methods and taking regular [Elasticsearch
-snapshots](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html)
+With the above methods and taking regular 
+[Elasticsearch snapshots](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html)
 we should be able to recover from different kinds of data loss issues in a
 relatively short period of time compared to indexing everything from
 scratch.
diff --git a/doc/development/emails.md b/doc/development/emails.md
index a5c2789a3ea..e4dfcc359a3 100644
--- a/doc/development/emails.md
+++ b/doc/development/emails.md
@@ -160,9 +160,10 @@ and Helm Chart configuration (see [example merge request](https://gitlab.com/git
 #### Rationale
 
 This was done because to avoid [thread deadlocks](https://github.com/ruby/net-imap/issues/14), `MailRoom` needs
-an updated version of the `net-imap` gem. However, this [version of the net-imap cannot be installed by an unprivileged
-user](https://github.com/ruby/net-imap/issues/14) due to [an error installing the digest
-gem](https://github.com/ruby/digest/issues/14). [This bug in the Ruby interpreter](https://bugs.ruby-lang.org/issues/17761) was fixed in Ruby
+an updated version of the `net-imap` gem. However, this 
+[version of the net-imap cannot be installed by an unprivileged user](https://github.com/ruby/net-imap/issues/14) due to 
+[an error installing the digest gem](https://github.com/ruby/digest/issues/14). 
+[This bug in the Ruby interpreter](https://bugs.ruby-lang.org/issues/17761) was fixed in Ruby
 3.0.2.
 
 Updating the gem directly in the GitLab Rails `Gemfile` caused a [production incident](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/4053)
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 0af45cb6887..3c7280b8e5a 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -729,8 +729,9 @@ In this case, we can either:
 - Skip passing a cursor.
 - Pass `null` explicitly to `after`.
 
-After data is fetched, we can use the `update`-hook as an opportunity [to customize
-the data that is set in the Vue component property](https://apollo.vuejs.org/api/smart-query.html#options). This allows us to get a hold of the `pageInfo` object among other data.
+After data is fetched, we can use the `update`-hook as an opportunity 
+[to customize the data that is set in the Vue component property](https://apollo.vuejs.org/api/smart-query.html#options). 
+This allows us to get a hold of the `pageInfo` object among other data.
 
 In the `result`-hook, we can inspect the `pageInfo` object to see if we need to fetch
 the next page. Note that we also keep a `requestCount` to ensure that the application
diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md
index 4b5fd6ffc07..469056e140a 100644
--- a/doc/development/fe_guide/performance.md
+++ b/doc/development/fe_guide/performance.md
@@ -77,9 +77,9 @@ performance.getEntriesByType('mark');
 performance.getEntriesByType('measure');
 ```
 
-Using `getEntriesByName()` or `getEntriesByType()` returns an Array of [the PerformanceMeasure
-objects](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceMeasure) which contain
-information about the measurement's start time and duration.
+Using `getEntriesByName()` or `getEntriesByType()` returns an Array of 
+[the PerformanceMeasure objects](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceMeasure) 
+which contain information about the measurement's start time and duration.
 
 ### User Timing API utility
 
diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md
index 064f01c8195..949e6a49e38 100644
--- a/doc/development/fe_guide/vuex.md
+++ b/doc/development/fe_guide/vuex.md
@@ -364,8 +364,8 @@ export default initialState => ({
 
 We made the conscious decision to avoid this pattern to improve the ability to
 discover and search our frontend codebase. The same applies
-when [providing data to a Vue app](vue.md#providing-data-from-haml-to-javascript). The reasoning for this is described in [this
-discussion](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/56#note_302514865):
+when [providing data to a Vue app](vue.md#providing-data-from-haml-to-javascript). The reasoning for this is described in 
+[this discussion](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/56#note_302514865):
 
 > Consider a `someStateKey` is being used in the store state. You _may_ not be
 > able to grep for it directly if it was provided only by `el.dataset`. Instead,
diff --git a/doc/development/feature_categorization/index.md b/doc/development/feature_categorization/index.md
index b2d141798fa..a93ed58336d 100644
--- a/doc/development/feature_categorization/index.md
+++ b/doc/development/feature_categorization/index.md
@@ -10,8 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Each Sidekiq worker, controller action, or API endpoint
 must declare a `feature_category` attribute. This attribute maps each
-of these to a [feature
-category](https://about.gitlab.com/handbook/product/categories/). This
+of these to a [feature category](https://about.gitlab.com/handbook/product/categories/). This
 is done for error budgeting, alert routing, and team attribution.
 
 The list of feature categories can be found in the file `config/feature_categories.yml`.
@@ -29,8 +28,7 @@ product categories. When this occurs, you can automatically update
 and generate a new version of the file, which needs to be committed to
 the repository.
 
-The [Scalability
-team](https://about.gitlab.com/handbook/engineering/infrastructure/team/scalability/)
+The [Scalability team](https://about.gitlab.com/handbook/engineering/infrastructure/team/scalability/)
 currently maintains the `feature_categories.yml` file. They will automatically be
 notified on Slack when the file becomes outdated.
 
diff --git a/doc/development/gemfile.md b/doc/development/gemfile.md
index 0fcfb88c9cd..f9cf69020bb 100644
--- a/doc/development/gemfile.md
+++ b/doc/development/gemfile.md
@@ -61,8 +61,7 @@ to a gem, go through these steps:
        1. Follow the [instructions for new projects](https://about.gitlab.com/handbook/engineering/gitlab-repositories/#creating-a-new-project).
        1. Follow the instructions for setting up a [CI/CD configuration](https://about.gitlab.com/handbook/engineering/gitlab-repositories/#cicd-configuration).
        1. Follow the instructions for [publishing a project](https://about.gitlab.com/handbook/engineering/gitlab-repositories/#publishing-a-project).
-   - See [issue
-     #325463](https://gitlab.com/gitlab-org/gitlab/-/issues/325463)
+   - See [issue #325463](https://gitlab.com/gitlab-org/gitlab/-/issues/325463)
      for an example.
    - In some cases we may want to move a gem to its own namespace. Some
      examples might be that it will naturally have more than one project
@@ -74,8 +73,8 @@ to a gem, go through these steps:
      apply if someone who currently works at GitLab wants to maintain
      the gem beyond their time working at GitLab.
 
-When publishing a gem to RubyGems.org, also note the section on [gem
-owners](https://about.gitlab.com/handbook/developer-onboarding/#ruby-gems)
+When publishing a gem to RubyGems.org, also note the section on 
+[gem owners](https://about.gitlab.com/handbook/developer-onboarding/#ruby-gems)
 in the handbook.
 
 ## Upgrade Rails
@@ -113,8 +112,7 @@ gem 'thor', '>= 1.1.1'
 ```
 
 Here we're using the operator `>=` (greater than or equal to) rather
-than `~>` ([pessimistic
-operator](https://thoughtbot.com/blog/rubys-pessimistic-operator))
+than `~>` ([pessimistic operator](https://thoughtbot.com/blog/rubys-pessimistic-operator))
 making it possible to upgrade `license_finder` or any other gem to a
 version that depends on `thor 1.2`.
 
@@ -134,15 +132,14 @@ that also relied on `thor` but had its version pinned to a vulnerable
 one. These changes are easy to miss in the `Gemfile.lock`. Pinning the
 version would result in a conflict that would need to be solved.
 
-To avoid upgrading indirect dependencies, we can use [`bundle update
---conservative`](https://bundler.io/man/bundle-update.1.html#OPTIONS).
+To avoid upgrading indirect dependencies, we can use 
+[`bundle update --conservative`](https://bundler.io/man/bundle-update.1.html#OPTIONS).
 
 When submitting a merge request including a dependency update,
 include a link to the Gem diff between the 2 versions in the merge request
 description. You can find this link on `rubygems.org`, select
 **Review Changes** to generate a comparison
 between the versions on `diffend.io`. For example, this is the gem
-diff for [`thor` 1.0.0 vs
-1.0.1](https://my.diffend.io/gems/thor/1.0.0/1.0.1). Use the
+diff for [`thor` 1.0.0 vs 1.0.1](https://my.diffend.io/gems/thor/1.0.0/1.0.1). Use the
 links directly generated from RubyGems, since the links from GitLab or other code-hosting
 platforms might not reflect the code that's actually published.
diff --git a/doc/development/geo/proxying.md b/doc/development/geo/proxying.md
index 41c7f426c6f..2f0226c489c 100644
--- a/doc/development/geo/proxying.md
+++ b/doc/development/geo/proxying.md
@@ -128,8 +128,8 @@ Secondary-->>Client: admin/geo/replication/projects logged in response (session
 
 ## Git pull
 
-For historical reasons, the `push_from_secondary` path is used to forward a Git pull. There is [an issue proposing to
-rename this route](https://gitlab.com/gitlab-org/gitlab/-/issues/292690) to avoid confusion.
+For historical reasons, the `push_from_secondary` path is used to forward a Git pull. There is 
+[an issue proposing to rename this route](https://gitlab.com/gitlab-org/gitlab/-/issues/292690) to avoid confusion.
 
 ### Git pull over HTTP(s)
 
diff --git a/doc/development/git_object_deduplication.md b/doc/development/git_object_deduplication.md
index 1a864ef81f0..a6b359769f8 100644
--- a/doc/development/git_object_deduplication.md
+++ b/doc/development/git_object_deduplication.md
@@ -18,8 +18,8 @@ GitLab implements Git object deduplication.
 
 ### Understanding Git alternates
 
-At the Git level, we achieve deduplication by using [Git
-alternates](https://git-scm.com/docs/gitrepository-layout#gitrepository-layout-objects).
+At the Git level, we achieve deduplication by using 
+[Git alternates](https://git-scm.com/docs/gitrepository-layout#gitrepository-layout-objects).
 Git alternates is a mechanism that lets a repository borrow objects from
 another repository on the same machine.
 
@@ -44,8 +44,8 @@ reliable decide if an object is no longer needed.
 
 ### Git alternates in GitLab: pool repositories
 
-GitLab organizes this object borrowing by [creating special **pool
-repositories**](../administration/repository_storage_types.md) which are hidden from the user. We then use Git
+GitLab organizes this object borrowing by [creating special **pool repositories**](../administration/repository_storage_types.md)
+which are hidden from the user. We then use Git
 alternates to let a collection of project repositories borrow from a
 single pool repository. We call such a collection of project
 repositories a pool. Pools form star-shaped networks of repositories
@@ -99,9 +99,8 @@ are as follows:
 
 ### Assumptions
 
-- All repositories in a pool must use [hashed
-  storage](../administration/repository_storage_types.md). This is so
-  that we don't have to ever worry about updating paths in
+- All repositories in a pool must use [hashed storage](../administration/repository_storage_types.md). 
+  This is so that we don't have to ever worry about updating paths in
   `object/info/alternates` files.
 - All repositories in a pool must be on the same Gitaly storage shard.
   The Git alternates mechanism relies on direct disk access across
diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md
index 8a0cf8e7717..66b535682f5 100644
--- a/doc/development/gitaly.md
+++ b/doc/development/gitaly.md
@@ -79,8 +79,7 @@ During RSpec tests, the Gitaly instance writes logs to `gitlab/log/gitaly-test.l
 While Gitaly can handle all Git access, many of GitLab customers still
 run Gitaly atop NFS. The legacy Rugged implementation for Git calls may
 be faster than the Gitaly RPC due to N+1 Gitaly calls and other
-reasons. See [the
-issue](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57317) for more
+reasons. See [the issue](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57317) for more
 details.
 
 Until GitLab has eliminated most of these inefficiencies or the use of
diff --git a/doc/development/github_importer.md b/doc/development/github_importer.md
index 963350def80..0aa1bad711d 100644
--- a/doc/development/github_importer.md
+++ b/doc/development/github_importer.md
@@ -71,8 +71,8 @@ This worker imports all pull requests. For every pull request a job for the
 
 ### 5. Stage::ImportPullRequestsMergedByWorker
 
-This worker imports the pull requests' _merged-by_ user information. The [_List pull
-requests_](https://docs.github.com/en/rest/pulls#list-pull-requests)
+This worker imports the pull requests' _merged-by_ user information. The 
+[_List pull requests_](https://docs.github.com/en/rest/pulls#list-pull-requests)
 API doesn't provide this information. Therefore, this stage must fetch each merged pull request
 individually to import this information. A
 `Gitlab::GithubImport::ImportPullRequestMergedByWorker` job is scheduled for each fetched pull
diff --git a/doc/development/go_guide/dependencies.md b/doc/development/go_guide/dependencies.md
index 0c2ce4f2b48..2a53fa590e3 100644
--- a/doc/development/go_guide/dependencies.md
+++ b/doc/development/go_guide/dependencies.md
@@ -44,9 +44,9 @@ end with a timestamp and the first 12 characters of the commit identifier:
 
 If a VCS tag matches one of these patterns, it is ignored.
 
-For a complete understanding of Go modules and versioning, see [this series of
-blog posts](https://go.dev/blog/using-go-modules) on the official Go
-website.
+For a complete understanding of Go modules and versioning, see 
+[this series of blog posts](https://go.dev/blog/using-go-modules) 
+on the official Go website.
 
 ## 'Module' vs 'Package'
 
diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md
index 4b99f50a941..711b0662a8c 100644
--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@@ -145,18 +145,16 @@ Go GitLab linter plugins are maintained in the [`gitlab-org/language-tools/go/li
 ## Dependencies
 
 Dependencies should be kept to the minimum. The introduction of a new
-dependency should be argued in the merge request, as per our [Approval
-Guidelines](../code_review.md#approval-guidelines). Both [License
-Scanning](../../user/compliance/license_compliance/index.md)
-**(ULTIMATE)** and [Dependency
-Scanning](../../user/application_security/dependency_scanning/index.md)
-**(ULTIMATE)** should be activated on all projects to ensure new dependencies
+dependency should be argued in the merge request, as per our [Approval Guidelines](../code_review.md#approval-guidelines). 
+Both [License Scanning](../../user/compliance/license_compliance/index.md)
+and [Dependency Scanning](../../user/application_security/dependency_scanning/index.md)
+should be activated on all projects to ensure new dependencies
 security status and license compatibility.
 
 ### Modules
 
-In Go 1.11 and later, a standard dependency system is available behind the name [Go
-Modules](https://github.com/golang/go/wiki/Modules). It provides a way to
+In Go 1.11 and later, a standard dependency system is available behind the name 
+[Go Modules](https://github.com/golang/go/wiki/Modules). It provides a way to
 define and lock dependencies for reproducible builds. It should be used
 whenever possible.
 
@@ -168,8 +166,8 @@ projects, and makes merge requests easier to review.
 In some cases, such as building a Go project for it to act as a dependency of a
 CI run for another project, removing the `vendor/` directory means the code must
 be downloaded repeatedly, which can lead to intermittent problems due to rate
-limiting or network failures. In these circumstances, you should [cache the
-downloaded code between](../../ci/caching/index.md#cache-go-dependencies).
+limiting or network failures. In these circumstances, you should 
+[cache the downloaded code between](../../ci/caching/index.md#cache-go-dependencies).
 
 There was a
 [bug on modules checksums](https://github.com/golang/go/issues/29278) in Go versions earlier than v1.11.4, so make
@@ -330,18 +328,15 @@ A few things to keep in mind when adding context:
 ### References for working with errors
 
 - [Go 1.13 errors](https://go.dev/blog/go1.13-errors).
-- [Programing with
-  errors](https://peter.bourgon.org/blog/2019/09/11/programming-with-errors.html).
-- [Don't just check errors, handle them
-  gracefully](https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully).
+- [Programing with errors](https://peter.bourgon.org/blog/2019/09/11/programming-with-errors.html).
+- [Don't just check errors, handle them gracefully](https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully).
 
 ## CLIs
 
 Every Go program is launched from the command line.
 [`cli`](https://github.com/urfave/cli) is a convenient package to create command
 line apps. It should be used whether the project is a daemon or a simple CLI
-tool. Flags can be mapped to [environment
-variables](https://github.com/urfave/cli#values-from-the-environment) directly,
+tool. Flags can be mapped to [environment variables](https://github.com/urfave/cli#values-from-the-environment) directly,
 which documents and centralizes at the same time all the possible command line
 interactions with the program. Don't use `os.GetEnv`, it hides variables deep
 in the code.
@@ -362,8 +357,7 @@ Every binary ideally must have structured (JSON) logging in place as it helps
 with searching and filtering the logs. At GitLab we use structured logging in
 JSON format, as all our infrastructure assumes that. When using
 [Logrus](https://github.com/sirupsen/logrus) you can turn on structured
-logging simply by using the build in [JSON
-formatter](https://github.com/sirupsen/logrus#formatters). This follows the
+logging simply by using the build in [JSON formatter](https://github.com/sirupsen/logrus#formatters). This follows the
 same logging type we use in our [Ruby applications](../logging.md#use-structured-json-logging).
 
 #### How to use Logrus
@@ -414,8 +408,7 @@ should be used in functions that can block and passed as the first parameter.
 Every project should have a `Dockerfile` at the root of their repository, to
 build and run the project. Since Go program are static binaries, they should
 not require any external dependency, and shells in the final image are useless.
-We encourage [Multistage
-builds](https://docs.docker.com/develop/develop-images/multistage-build/):
+We encourage [Multistage builds](https://docs.docker.com/develop/develop-images/multistage-build/):
 
 - They let the user build the project with the right Go version and
   dependencies.
diff --git a/doc/development/gotchas.md b/doc/development/gotchas.md
index d89dbbcf904..af11340737f 100644
--- a/doc/development/gotchas.md
+++ b/doc/development/gotchas.md
@@ -200,8 +200,7 @@ refresh_service.execute(oldrev, newrev, ref)
 
 See ["Why is it bad style to `rescue Exception => e` in Ruby?"](https://stackoverflow.com/questions/10048173/why-is-it-bad-style-to-rescue-exception-e-in-ruby).
 
-This rule is [enforced automatically by
-RuboCop](https://gitlab.com/gitlab-org/gitlab-foss/blob/8-4-stable/.rubocop.yml#L911-914)._
+This rule is [enforced automatically by RuboCop](https://gitlab.com/gitlab-org/gitlab-foss/blob/8-4-stable/.rubocop.yml#L911-914)._
 
 ## Do not use inline JavaScript in views
 
diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index 37ab71e2b34..a02fc018969 100644
--- a/doc/development/integrations/secure.md
+++ b/doc/development/integrations/secure.md
@@ -509,8 +509,8 @@ which is shared by some of the analyzers that GitLab maintains. You can [contrib
 new generic identifiers to if needed. Analyzers may also produce vendor-specific or product-specific
 identifiers, which don't belong in the [common library](https://gitlab.com/gitlab-org/security-products/analyzers/common).
 
-The first item of the `identifiers` array is called the [primary
-identifier](../../user/application_security/terminology/#primary-identifier).
+The first item of the `identifiers` array is called the 
+[primary identifier](../../user/application_security/terminology/index.md#primary-identifier).
 The primary identifier is particularly important, because it is used to
 [track vulnerabilities](#tracking-and-merging-vulnerabilities) as new commits are pushed to the repository.
 Identifiers are also used to [merge duplicate vulnerabilities](#tracking-and-merging-vulnerabilities)
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index 23915b73fb2..7ff25705ae6 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -394,8 +394,8 @@ query for every mention of `@alice`.
 Caching data per transaction can be done using
 [RequestStore](https://github.com/steveklabnik/request_store) (use
 `Gitlab::SafeRequestStore` to avoid having to remember to check
-`RequestStore.active?`). Caching data in Redis can be done using [Rails' caching
-system](https://guides.rubyonrails.org/caching_with_rails.html).
+`RequestStore.active?`). Caching data in Redis can be done using 
+[Rails' caching system](https://guides.rubyonrails.org/caching_with_rails.html).
 
 ## Pagination
 
@@ -414,8 +414,7 @@ The main styles of pagination are:
 
 The ultimately scalable solution for pagination is to use Keyset-based pagination.
 However, we don't have support for that at GitLab at that moment. You
-can follow the progress looking at [API: Keyset Pagination
-](https://gitlab.com/groups/gitlab-org/-/epics/2039).
+can follow the progress looking at [API: Keyset Pagination](https://gitlab.com/groups/gitlab-org/-/epics/2039).
 
 Take into consideration the following when choosing a pagination strategy:
 
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 5963c7f3ef4..bb38d094d2d 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -1197,8 +1197,8 @@ If using a model in the migrations, you should first
 [clear the column cache](https://api.rubyonrails.org/classes/ActiveRecord/ModelSchema/ClassMethods.html#method-i-reset_column_information)
 using `reset_column_information`.
 
-If using a model that leverages single table inheritance (STI), there are [special
-considerations](database/single_table_inheritance.md#in-migrations).
+If using a model that leverages single table inheritance (STI), there are 
+[special considerations](database/single_table_inheritance.md#in-migrations).
 
 This avoids problems where a column that you are using was altered and cached
 in a previous migration.
diff --git a/doc/development/module_with_instance_variables.md b/doc/development/module_with_instance_variables.md
index 0f910f20534..8e39186d396 100644
--- a/doc/development/module_with_instance_variables.md
+++ b/doc/development/module_with_instance_variables.md
@@ -35,12 +35,10 @@ one of the variables. Everything could touch anything.
 People are saying multiple inheritance is bad. Mixing multiple modules with
 multiple instance variables scattering everywhere suffer from the same issue.
 The same applies to `ActiveSupport::Concern`. See:
-[Consider replacing concerns with dedicated classes & composition](
-https://gitlab.com/gitlab-org/gitlab/-/issues/16270)
+[Consider replacing concerns with dedicated classes & composition](https://gitlab.com/gitlab-org/gitlab/-/issues/16270)
 
 There's also a similar idea:
-[Use decorators and interface segregation to solve overgrowing models problem](
-https://gitlab.com/gitlab-org/gitlab/-/issues/14235)
+[Use decorators and interface segregation to solve overgrowing models problem](https://gitlab.com/gitlab-org/gitlab/-/issues/14235)
 
 Note that `included` doesn't solve the whole issue. They define the
 dependencies, but they still allow each modules to talk implicitly via the
diff --git a/doc/development/performance.md b/doc/development/performance.md
index e5203f9c529..0801a9cfbab 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -927,8 +927,7 @@ SOME_CONSTANT = 'bar'
 
 You might want millions of project rows in your local database, for example,
 in order to compare relative query performance, or to reproduce a bug. You could
-do this by hand with SQL commands or using [Mass Inserting Rails
-Models](mass_insert.md) functionality.
+do this by hand with SQL commands or using [Mass Inserting Rails Models](mass_insert.md) functionality.
 
 Assuming you are working with ActiveRecord models, you might also find these links helpful:
 
diff --git a/doc/development/policies.md b/doc/development/policies.md
index c9e4fdb4350..f0c9d0ec5f9 100644
--- a/doc/development/policies.md
+++ b/doc/development/policies.md
@@ -74,8 +74,7 @@ Do not use boolean operators such as `&&` and `||` within the rule DSL,
 as conditions within rule blocks are objects, not booleans. The same
 applies for ternary operators (`condition ? ... : ...`), and `if`
 blocks. These operators cannot be overridden, and are hence banned via a
-[custom
-cop](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49771).
+[custom cop](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49771).
 
 ## Scores, Order, Performance
 
diff --git a/doc/development/rails_update.md b/doc/development/rails_update.md
index 36ffae97377..9907a78421f 100644
--- a/doc/development/rails_update.md
+++ b/doc/development/rails_update.md
@@ -27,8 +27,8 @@ We strive to run GitLab using the latest Rails releases to benefit from performa
 1. Run `yarn patch-package @rails/ujs` after updating this to ensure our local patch file version matches.
 1. Create an MR with the `pipeline:run-all-rspec` label and see if pipeline breaks.
 1. To resolve and debug spec failures use `git bisect` against the rails repository. See the [debugging section](#git-bisect-against-rails) below.
-1. Include links to the Gem diffs between the two versions in the merge request description. For example, this is the gem diff for [`activesupport` 6.1.3.2 to
-6.1.4.1](https://my.diffend.io/gems/activerecord/6.1.3.2/6.1.4.1).
+1. Include links to the Gem diffs between the two versions in the merge request description. For example, this is the gem diff for 
+   [`activesupport` 6.1.3.2 to 6.1.4.1](https://my.diffend.io/gems/activerecord/6.1.3.2/6.1.4.1).
 
 ### Prepare an MR for Gitaly
 
diff --git a/doc/development/redis/new_redis_instance.md b/doc/development/redis/new_redis_instance.md
index 4900755b58c..8731cc469ce 100644
--- a/doc/development/redis/new_redis_instance.md
+++ b/doc/development/redis/new_redis_instance.md
@@ -265,7 +265,7 @@ instances to cope without this functional partition.
 If we decide to keep the migration code:
 
 - We should document the migration steps.
-- If we used a feature flag, we should ensure it's an [ops type feature
-  flag](../feature_flags/index.md#ops-type), as these are long-lived flags.
+- If we used a feature flag, we should ensure it's an 
+  [ops type feature flag](../feature_flags/index.md#ops-type), as these are long-lived flags.
 
 Otherwise, we can remove the flags and conclude the project.
diff --git a/doc/development/routing.md b/doc/development/routing.md
index 2b3ecd8127b..3d5857b4237 100644
--- a/doc/development/routing.md
+++ b/doc/development/routing.md
@@ -6,8 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Routing
 
-The GitLab backend is written primarily with Rails so it uses [Rails
-routing](https://guides.rubyonrails.org/routing.html). Beside Rails best
+The GitLab backend is written primarily with Rails so it uses 
+[Rails routing](https://guides.rubyonrails.org/routing.html). Beside Rails best
 practices, there are few rules unique to the GitLab application. To
 support subgroups, GitLab project and group routes use the wildcard
 character to match project and group routes. For example, we might have
diff --git a/doc/development/scalability.md b/doc/development/scalability.md
index d9fa47f41be..b7ee0ca1167 100644
--- a/doc/development/scalability.md
+++ b/doc/development/scalability.md
@@ -35,8 +35,8 @@ The application has a tight coupling to the database schema. When the
 application starts, Rails queries the database schema, caching the tables and
 column types for the data requested. Because of this schema cache, dropping a
 column or table while the application is running can produce 500 errors to the
-user. This is why we have a [process for dropping columns and other
-no-downtime changes](database/avoiding_downtime_in_migrations.md).
+user. This is why we have a 
+[process for dropping columns and other no-downtime changes](database/avoiding_downtime_in_migrations.md).
 
 #### Multi-tenancy
 
@@ -61,11 +61,11 @@ There are two ways to deal with this:
 - Sharding. Distribute data across multiple databases.
 
 Partitioning is a built-in PostgreSQL feature and requires minimal changes
-in the application. However, it [requires PostgreSQL
-11](https://www.2ndquadrant.com/en/blog/partitioning-evolution-postgresql-11/).
+in the application. However, it 
+[requires PostgreSQL 11](https://www.2ndquadrant.com/en/blog/partitioning-evolution-postgresql-11/).
 
-For example, a natural way to partition is to [partition tables by
-dates](https://gitlab.com/groups/gitlab-org/-/epics/2023). For example,
+For example, a natural way to partition is to 
+[partition tables by dates](https://gitlab.com/groups/gitlab-org/-/epics/2023). For example,
 the `events` and `audit_events` table are natural candidates for this
 kind of partitioning.
 
@@ -77,10 +77,10 @@ to abstract data access into API calls that abstract the database from
 the application, but this is a significant amount of work.
 
 There are solutions that may help abstract the sharding to some extent
-from the application. For example, we want to look at [Citus
-Data](https://www.citusdata.com/product/community) closely. Citus Data
-provides a Rails plugin that adds a [tenant ID to ActiveRecord
-models](https://www.citusdata.com/blog/2017/01/05/easily-scale-out-multi-tenant-apps/).
+from the application. For example, we want to look at 
+[Citus Data](https://www.citusdata.com/product/community) closely. Citus Data
+provides a Rails plugin that adds a 
+[tenant ID to ActiveRecord models](https://www.citusdata.com/blog/2017/01/05/easily-scale-out-multi-tenant-apps/).
 
 Sharding can also be done based on feature verticals. This is the
 microservice approach to sharding, where each service represents a
@@ -97,12 +97,12 @@ systems.
 
 #### Database size
 
-A recent [database checkup shows a breakdown of the table sizes on
-GitLab.com](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/8022#master-1022016101-8).
+A recent 
+[database checkup shows a breakdown of the table sizes on GitLab.com](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/8022#master-1022016101-8).
 Since `merge_request_diff_files` contains over 1 TB of data, we want to
-reduce/eliminate this table first. GitLab has support for [storing diffs in
-object storage](../administration/merge_request_diffs.md), which we [want to do on
-GitLab.com](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/7356).
+reduce/eliminate this table first. GitLab has support for 
+[storing diffs in object storage](../administration/merge_request_diffs.md), which we 
+[want to do on GitLab.com](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/7356).
 
 #### High availability
 
@@ -128,8 +128,7 @@ some actions that aren't traditionally available in standard load balancers. For
 example, the application considers a replica only if its replication lag is low
 (for example, WAL data behind by less than 100 MB).
 
-More [details are in a blog
-post](https://about.gitlab.com/blog/2017/10/02/scaling-the-gitlab-database/).
+More [details are in a blog post](https://about.gitlab.com/blog/2017/10/02/scaling-the-gitlab-database/).
 
 ### PgBouncer
 
@@ -150,8 +149,8 @@ limitation:
 - Use a multi-threaded connection pooler (for example,
   [Odyssey](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/7776).
 
-On some Linux systems, it's possible to run [multiple PgBouncer instances on
-the same port](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4796).
+On some Linux systems, it's possible to run 
+[multiple PgBouncer instances on the same port](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4796).
 
 On GitLab.com, we run multiple PgBouncer instances on different ports to
 avoid saturating a single core.
diff --git a/doc/development/sidekiq/compatibility_across_updates.md b/doc/development/sidekiq/compatibility_across_updates.md
index 96a3573d11a..a9897929596 100644
--- a/doc/development/sidekiq/compatibility_across_updates.md
+++ b/doc/development/sidekiq/compatibility_across_updates.md
@@ -18,15 +18,14 @@ several possible situations:
 
 ## Adding new workers
 
-On GitLab.com, we [do not currently have a Sidekiq deployment in the
-canary stage](https://gitlab.com/gitlab-org/gitlab/-/issues/19239). This
-means that a new worker than can be scheduled from an HTTP endpoint may
+On GitLab.com, we 
+[do not currently have a Sidekiq deployment in the canary stage](https://gitlab.com/gitlab-org/gitlab/-/issues/19239). 
+This means that a new worker than can be scheduled from an HTTP endpoint may
 be scheduled from canary but not run on Sidekiq until the full
 production deployment is complete. This can be several hours later than
 scheduling the job. For some workers, this will not be a problem. For
-others - particularly [latency-sensitive
-jobs](worker_attributes.md#latency-sensitive-jobs) - this will result in a poor user
-experience.
+others - particularly [latency-sensitive jobs](worker_attributes.md#latency-sensitive-jobs) - 
+this will result in a poor user experience.
 
 This only applies to new worker classes when they are first introduced.
 As we recommend [using feature flags](../feature_flags/) as a general
diff --git a/doc/development/sidekiq/idempotent_jobs.md b/doc/development/sidekiq/idempotent_jobs.md
index a5ae8737ad1..5d1ebce763e 100644
--- a/doc/development/sidekiq/idempotent_jobs.md
+++ b/doc/development/sidekiq/idempotent_jobs.md
@@ -78,9 +78,8 @@ GitLab supports two deduplication strategies:
 - `until_executing`, which is the default strategy
 - `until_executed`
 
-More [deduplication strategies have been
-suggested](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/195). If
-you are implementing a worker that could benefit from a different
+More [deduplication strategies have been suggested](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/195). 
+If you are implementing a worker that could benefit from a different
 strategy, please comment in the issue.
 
 #### Until Executing
diff --git a/doc/development/sidekiq/index.md b/doc/development/sidekiq/index.md
index c9906c4c768..7ee6ad9e643 100644
--- a/doc/development/sidekiq/index.md
+++ b/doc/development/sidekiq/index.md
@@ -31,8 +31,7 @@ the [routing rules](../../administration/operations/extra_sidekiq_routing.md#que
 
 ## Retries
 
-Sidekiq defaults to using [25
-retries](https://github.com/mperham/sidekiq/wiki/Error-Handling#automatic-job-retry),
+Sidekiq defaults to using [25 retries](https://github.com/mperham/sidekiq/wiki/Error-Handling#automatic-job-retry),
 with back-off between each retry. 25 retries means that the last retry
 would happen around three weeks after the first attempt (assuming all 24
 prior retries failed).
@@ -179,8 +178,7 @@ in the default execution mode - using
 [`sidekiq-cluster`](../../administration/operations/extra_sidekiq_processes.md)
 does not account for weights.
 
-As we are [moving towards using `sidekiq-cluster` in
-Free](https://gitlab.com/gitlab-org/gitlab/-/issues/34396), newly-added
+As we are [moving towards using `sidekiq-cluster` in Free](https://gitlab.com/gitlab-org/gitlab/-/issues/34396), newly-added
 workers do not need to have weights specified. They can use the
 default weight, which is 1.
 
diff --git a/doc/development/sidekiq/logging.md b/doc/development/sidekiq/logging.md
index 474ea5de951..fe823ee2594 100644
--- a/doc/development/sidekiq/logging.md
+++ b/doc/development/sidekiq/logging.md
@@ -11,8 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/9) in GitLab 12.8.
 
 To have some more information about workers in the logs, we add
-[metadata to the jobs in the form of an
-`ApplicationContext`](../logging.md#logging-context-metadata-through-rails-or-grape-requests).
+[metadata to the jobs in the form of an `ApplicationContext`](../logging.md#logging-context-metadata-through-rails-or-grape-requests).
 In most cases, when scheduling a job from a request, this context is already
 deducted from the request and added to the scheduled job.
 
diff --git a/doc/development/sidekiq/worker_attributes.md b/doc/development/sidekiq/worker_attributes.md
index 6820627f761..a1d24d0c392 100644
--- a/doc/development/sidekiq/worker_attributes.md
+++ b/doc/development/sidekiq/worker_attributes.md
@@ -86,13 +86,11 @@ but that always reduces work.
 To do this, we want to calculate the expected increase in total execution time
 and RPS (throughput) for the new shard. We can get these values from:
 
-- The [Queue Detail
-  dashboard](https://dashboards.gitlab.net/d/sidekiq-queue-detail/sidekiq-queue-detail)
+- The [Queue Detail dashboard](https://dashboards.gitlab.net/d/sidekiq-queue-detail/sidekiq-queue-detail)
   has values for the queue itself. For a new queue, we can look for
   queues that have similar patterns or are scheduled in similar
   circumstances.
-- The [Shard Detail
-  dashboard](https://dashboards.gitlab.net/d/sidekiq-shard-detail/sidekiq-shard-detail)
+- The [Shard Detail dashboard](https://dashboards.gitlab.net/d/sidekiq-shard-detail/sidekiq-shard-detail)
   has Total Execution Time and Throughput (RPS). The Shard Utilization
   panel displays if there is currently any excess capacity for this
   shard.
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index ea36214f6b7..79a72981e3f 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -422,8 +422,8 @@ Use the coverage reports to ensure your tests cover 100% of your code.
 ### System / Feature tests
 
 NOTE:
-Before writing a new system test, [please consider **not**
-writing one](testing_levels.md#consider-not-writing-a-system-test)!
+Before writing a new system test, 
+[please consider **not** writing one](testing_levels.md#consider-not-writing-a-system-test)!
 
 - Feature specs should be named `ROLE_ACTION_spec.rb`, such as
   `user_changes_password_spec.rb`.
@@ -909,8 +909,8 @@ By default, Sidekiq jobs are enqueued into a jobs array and aren't processed.
 If a test queues Sidekiq jobs and need them to be processed, the
 `:sidekiq_inline` trait can be used.
 
-The `:sidekiq_might_not_need_inline` trait was added when [Sidekiq inline mode was
-changed to fake mode](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/15479)
+The `:sidekiq_might_not_need_inline` trait was added when 
+[Sidekiq inline mode was changed to fake mode](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/15479)
 to all the tests that needed Sidekiq to actually process jobs. Tests with
 this trait should be either fixed to not rely on Sidekiq processing jobs, or their
 `:sidekiq_might_not_need_inline` trait should be updated to `:sidekiq_inline` if
@@ -1239,8 +1239,7 @@ The `match_schema` matcher allows validating that the subject matches a
 a JSON string or a JSON-compatible data structure.
 
 `match_response_schema` is a convenience matcher for using with a
-response object. from a [request
-spec](testing_levels.md#integration-tests).
+response object. from a [request spec](testing_levels.md#integration-tests).
 
 Examples:
 
diff --git a/doc/development/testing_guide/end_to_end/best_practices.md b/doc/development/testing_guide/end_to_end/best_practices.md
index 00b843ffdbe..bfda94b1f1d 100644
--- a/doc/development/testing_guide/end_to_end/best_practices.md
+++ b/doc/development/testing_guide/end_to_end/best_practices.md
@@ -415,8 +415,8 @@ except(page).to have_no_text('hidden')
 Unfortunately, that's not automatically the case for the predicate methods that we add to our
 [page objects](page_objects.md). We need to [create our own negatable matchers](https://relishapp.com/rspec/rspec-expectations/v/3-9/docs/custom-matchers/define-a-custom-matcher#matcher-with-separate-logic-for-expect().to-and-expect().not-to).
 
-The initial example uses the `have_job` matcher which is derived from the [`has_job?` predicate
-method of the `Page::Project::Pipeline::Show` page object](https://gitlab.com/gitlab-org/gitlab/-/blob/87864b3047c23b4308f59c27a3757045944af447/qa/qa/page/project/pipeline/show.rb#L53).
+The initial example uses the `have_job` matcher which is derived from the 
+[`has_job?` predicate method of the `Page::Project::Pipeline::Show` page object](https://gitlab.com/gitlab-org/gitlab/-/blob/87864b3047c23b4308f59c27a3757045944af447/qa/qa/page/project/pipeline/show.rb#L53).
 To create a negatable matcher, we use `has_no_job?` for the negative case:
 
 ```ruby
diff --git a/doc/development/testing_guide/end_to_end/feature_flags.md b/doc/development/testing_guide/end_to_end/feature_flags.md
index cb4c8e8a6e8..33f73304a26 100644
--- a/doc/development/testing_guide/end_to_end/feature_flags.md
+++ b/doc/development/testing_guide/end_to_end/feature_flags.md
@@ -217,8 +217,8 @@ If enabling the feature flag results in E2E test failures, you can browse the ar
 
 If an end-to-end test enables a feature flag, the end-to-end test suite can be used to test changes in a merge request
 by running the `package-and-qa` job in the merge request pipeline. If the feature flag and relevant changes have already been merged, you can confirm that the tests
-pass on the default branch. The end-to-end tests run on the default branch every two hours, and the results are posted to a [Test
-Session Report, which is available in the testcase-sessions project](https://gitlab.com/gitlab-org/quality/testcase-sessions/-/issues?label_name%5B%5D=found%3Amain).
+pass on the default branch. The end-to-end tests run on the default branch every two hours, and the results are posted to a 
+[Test Session Report, which is available in the testcase-sessions project](https://gitlab.com/gitlab-org/quality/testcase-sessions/-/issues?label_name%5B%5D=found%3Amain).
 
 If the relevant tests do not enable the feature flag themselves, you can check if the tests will need to be updated by opening
 a draft merge request that enables the flag by default via a [feature flag definition file](../../feature_flags/index.md#feature-flag-definition-and-validation).
diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index b2d9ea85b05..989d090d581 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -140,8 +140,8 @@ a flaky test we first want to make sure that it's no longer flaky.
 We can do that using the `ce:custom-parallel` and `ee:custom-parallel` jobs.
 Both are manual jobs that you can configure using custom variables.
 When clicking the name (not the play icon) of one of the parallel jobs,
-you are prompted to enter variables. You can use any of [the variables
-that can be used with `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#supported-gitlab-environment-variables)
+you are prompted to enter variables. You can use any of 
+[the variables that can be used with `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#supported-gitlab-environment-variables)
 as well as these:
 
 | Variable | Description |
@@ -150,8 +150,9 @@ as well as these:
 | `QA_TESTS` | The tests to run (no default, which means run all the tests in the scenario). Use file paths as you would when running tests via RSpec, for example, `qa/specs/features/ee/browser_ui` would include all the `EE` UI tests. |
 | `QA_RSPEC_TAGS` | The RSpec tags to add (no default) |
 
-For now, [manual jobs with custom variables don't use the same variable
-when retried](https://gitlab.com/gitlab-org/gitlab/-/issues/31367), so if you want to run the same tests multiple times,
+For now, 
+[manual jobs with custom variables don't use the same variable when retried](https://gitlab.com/gitlab-org/gitlab/-/issues/31367), 
+so if you want to run the same tests multiple times,
 specify the same variables in each `custom-parallel` job (up to as
 many of the 10 available jobs that you want to run).
 
@@ -164,8 +165,8 @@ automatically started: it runs the QA smoke suite against the
 You can also manually start the `review-qa-all`: it runs the full QA suite
 against the [Review App](../review_apps.md).
 
-**This runs end-to-end tests against a Review App based on [the official GitLab
-Helm chart](https://gitlab.com/gitlab-org/charts/gitlab/), itself deployed with custom
+**This runs end-to-end tests against a Review App based on 
+[the official GitLab Helm chart](https://gitlab.com/gitlab-org/charts/gitlab/), itself deployed with custom
 [Cloud Native components](https://gitlab.com/gitlab-org/build/CNG) built from your merge request's changes.**
 
 See [Review Apps](../review_apps.md) for more details about Review Apps.
@@ -243,8 +244,8 @@ Each type of scheduled pipeline generates a static link for the latest test repo
 If you are not [testing code in a merge request](#testing-code-in-merge-requests),
 there are two main options for running the tests. If you want to run
 the existing tests against a live GitLab instance or against a pre-built Docker image,
-use the [GitLab QA orchestrator](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/README.md). See also [examples
-of the test scenarios you can run via the orchestrator](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#examples).
+use the [GitLab QA orchestrator](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/README.md). See also 
+[examples of the test scenarios you can run via the orchestrator](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#examples).
 
 On the other hand, if you would like to run against a local development GitLab
 environment, you can use the [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/).
@@ -262,8 +263,8 @@ architecture. See the [documentation about it](https://gitlab.com/gitlab-org/git
 
 Once you decided where to put [test environment orchestration scenarios](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/lib/gitlab/qa/scenario) and
 [instance-level scenarios](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/specs/features), take a look at the [GitLab QA README](https://gitlab.com/gitlab-org/gitlab/-/tree/master/qa/README.md),
-the [GitLab QA orchestrator README](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/README.md), and [the already existing
-instance-level scenarios](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/specs/features).
+the [GitLab QA orchestrator README](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/README.md), 
+and [the already existing instance-level scenarios](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/specs/features).
 
 ### Consider **not** writing an end-to-end test
 
diff --git a/doc/development/testing_guide/index.md b/doc/development/testing_guide/index.md
index fa9f1f1ac3e..cd7c70e2eaa 100644
--- a/doc/development/testing_guide/index.md
+++ b/doc/development/testing_guide/index.md
@@ -9,8 +9,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 This document describes various guidelines and best practices for automated
 testing of the GitLab project.
 
-It is meant to be an _extension_ of the [Thoughtbot testing
-style guide](https://github.com/thoughtbot/guides/tree/master/testing-rspec). If
+It is meant to be an _extension_ of the 
+[Thoughtbot testing style guide](https://github.com/thoughtbot/guides/tree/master/testing-rspec). If
 this guide defines a rule that contradicts the Thoughtbot guide, this guide
 takes precedence. Some guidelines may be repeated verbatim to stress their
 importance.
diff --git a/doc/development/testing_guide/testing_migrations_guide.md b/doc/development/testing_guide/testing_migrations_guide.md
index d71788e21f3..261a4f4a27e 100644
--- a/doc/development/testing_guide/testing_migrations_guide.md
+++ b/doc/development/testing_guide/testing_migrations_guide.md
@@ -317,8 +317,8 @@ To test these you usually have to:
 - Verify that the expected jobs were scheduled, with the correct set
   of records, the correct batch size, interval, etc.
 
-The behavior of the background migration itself needs to be verified in a [separate
-test for the background migration class](#example-background-migration-test).
+The behavior of the background migration itself needs to be verified in a 
+[separate test for the background migration class](#example-background-migration-test).
 
 This spec tests the
 [`db/post_migrate/20210701111909_backfill_issues_upvotes_count.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/v14.1.0-ee/db/post_migrate/20210701111909_backfill_issues_upvotes_count.rb)
diff --git a/doc/development/windows.md b/doc/development/windows.md
index 3eed9c057ab..17dfaddef36 100644
--- a/doc/development/windows.md
+++ b/doc/development/windows.md
@@ -37,8 +37,7 @@ A list of software preinstalled on the Windows images is available at: [Preinsta
 
 ## GCP Windows image for development
 
-The [shared Windows GitLab
-runners](https://about.gitlab.com/releases/2020/01/22/gitlab-12-7-released/#windows-shared-runners-on-gitlabcom-beta)
+The [shared Windows GitLab runners](https://about.gitlab.com/releases/2020/01/22/gitlab-12-7-released/#windows-shared-runners-on-gitlabcom-beta)
 are built with [Packer](https://www.packer.io/).
 
 The Infrastructure as Code repository for building the Google Cloud images is available at:
diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md
index 0d621217dd8..7f155a78140 100644
--- a/doc/install/azure/index.md
+++ b/doc/install/azure/index.md
@@ -233,8 +233,8 @@ The first thing that appears is the sign-in page. GitLab creates an administrato
 The credentials are:
 
 - Username: `root`
-- Password: the password is automatically created, and there are [two ways to
-  find it](https://docs.bitnami.com/azure/faq/get-started/find-credentials/).
+- Password: the password is automatically created, and there are 
+  [two ways to find it](https://docs.bitnami.com/azure/faq/get-started/find-credentials/).
 
 After signing in, be sure to immediately [change the password](../../user/profile/index.md#change-your-password).
 
diff --git a/doc/install/installation.md b/doc/install/installation.md
index cb48ef5abc9..0b731161529 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -129,8 +129,8 @@ sudo apt-get install libkrb5-dev
 
 ### Git
 
-From GitLab 13.6, we recommend you use the [Git version provided by
-Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729)
+From GitLab 13.6, we recommend you use the 
+[Git version provided by Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729)
 that:
 
 - Is always at the version required by GitLab.
@@ -239,8 +239,8 @@ sudo make install
 
 GitLab has several daemons written in Go. To install
 GitLab we need a Go compiler. The instructions below assume you use 64-bit
-Linux. You can find downloads for other platforms at the [Go download
-page](https://go.dev/dl).
+Linux. You can find downloads for other platforms at the 
+[Go download page](https://go.dev/dl).
 
 ```shell
 # Remove former Go installation folder
diff --git a/doc/integration/advanced_search/elasticsearch.md b/doc/integration/advanced_search/elasticsearch.md
index f551723c150..dbea3b84421 100644
--- a/doc/integration/advanced_search/elasticsearch.md
+++ b/doc/integration/advanced_search/elasticsearch.md
@@ -466,8 +466,7 @@ Before doing a major version GitLab upgrade, you should have completed all
 migrations that exist up until the latest minor version before that major
 version. If you have halted migrations, these need to be resolved and
 [retried](#retry-a-halted-migration) before proceeding with a major version
-upgrade. Read more about [upgrading to a new major
-version](../../update/index.md#upgrading-to-a-new-major-version).
+upgrade. Read more about [upgrading to a new major version](../../update/index.md#upgrading-to-a-new-major-version).
 
 ## GitLab Advanced Search Rake tasks
 
@@ -577,9 +576,9 @@ due to large volumes of data being indexed.
 
 WARNING:
 Indexing a large instance generates a lot of Sidekiq jobs.
-Make sure to prepare for this task by having a [Scalable and Highly Available
-Setup](../../administration/reference_architectures/index.md) or creating [extra
-Sidekiq processes](../../administration/operations/extra_sidekiq_processes.md).
+Make sure to prepare for this task by having a 
+[Scalable and Highly Available Setup](../../administration/reference_architectures/index.md) or creating 
+[extra Sidekiq processes](../../administration/operations/extra_sidekiq_processes.md).
 
 1. [Configure your Elasticsearch host and port](#enable-advanced-search).
 1. Create empty indices:
diff --git a/doc/integration/mattermost/index.md b/doc/integration/mattermost/index.md
index 99678c9a1d3..3293732b59b 100644
--- a/doc/integration/mattermost/index.md
+++ b/doc/integration/mattermost/index.md
@@ -447,8 +447,7 @@ mattermost['env'] = {
                     }
 ```
 
-Refer to the [Mattermost Configuration Settings
-documentation](https://docs.mattermost.com/administration/config-settings.html)
+Refer to the [Mattermost Configuration Settings documentation](https://docs.mattermost.com/administration/config-settings.html)
 for details about categories and configuration values.
 
 There are a few exceptions to this rule:
diff --git a/doc/integration/saml.md b/doc/integration/saml.md
index 5906d330a0e..6dd9f6e72c5 100644
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@@ -939,8 +939,8 @@ Make sure this information is provided.
 
 Another issue that can result in this error is when the correct information is being sent by
 the IdP, but the attributes don't match the names in the OmniAuth `info` hash. In this case,
-you must set `attribute_statements` in the SAML configuration to [map the attribute names in
-your SAML Response to the corresponding OmniAuth `info` hash names](#attribute_statements).
+you must set `attribute_statements` in the SAML configuration to 
+[map the attribute names in your SAML Response to the corresponding OmniAuth `info` hash names](#attribute_statements).
 
 ### Key validation error, Digest mismatch or Fingerprint mismatch
 
diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md
index e831303988b..e77a0459150 100644
--- a/doc/policy/maintenance.md
+++ b/doc/policy/maintenance.md
@@ -16,8 +16,8 @@ Our current policy is:
 - Backporting security fixes **to the previous two monthly releases in addition to the current stable release**. (See [security releases](#security-releases).)
 
 In rare cases, release managers may make an exception and backport to more than
-the last two monthly releases. See [Backporting to older
-releases](#backporting-to-older-releases) for more information.
+the last two monthly releases. See 
+[Backporting to older releases](#backporting-to-older-releases) for more information.
 
 ## Versioning
 
diff --git a/doc/raketasks/backup_gitlab.md b/doc/raketasks/backup_gitlab.md
index 8d5ae14a043..4629364ce3d 100644
--- a/doc/raketasks/backup_gitlab.md
+++ b/doc/raketasks/backup_gitlab.md
@@ -452,8 +452,9 @@ gitlab_rails['backup_upload_storage_options'] = {
 
 ##### SSE-KMS
 
-To enable SSE-KMS, you'll need the [KMS key via its Amazon Resource Name (ARN)
-in the `arn:aws:kms:region:acct-id:key/key-id` format](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html). Under the `backup_upload_storage_options` configuration setting, set:
+To enable SSE-KMS, you'll need the 
+[KMS key via its Amazon Resource Name (ARN) in the `arn:aws:kms:region:acct-id:key/key-id` format](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html). 
+Under the `backup_upload_storage_options` configuration setting, set:
 
 - `server_side_encryption` to `aws:kms`.
 - `server_side_encryption_kms_key_id` to the ARN of the key.
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index cf12e3f9719..bc2cca315e1 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -12,8 +12,8 @@ An application data backup creates an archive file that contains the database,
 all repositories and all attachments.
 
 You can only restore a backup to **exactly the same version and type (CE/EE)**
-of GitLab on which it was created. The best way to [migrate your projects
-from one server to another](#migrate-to-a-new-server) is through a backup and restore.
+of GitLab on which it was created. The best way to 
+[migrate your projects from one server to another](#migrate-to-a-new-server) is through a backup and restore.
 
 WARNING:
 GitLab doesn't back up items that aren't stored on the file system. If you're
@@ -190,8 +190,8 @@ tables will [be logged by PostgreSQL](../administration/logs/index.md#postgresql
 ERROR: relation "tablename" does not exist at character 123
 ```
 
-This happens because the task uses `pg_dump`, which [sets a null search
-path and explicitly includes the schema in every SQL query](https://gitlab.com/gitlab-org/gitlab/-/issues/23211)
+This happens because the task uses `pg_dump`, which 
+[sets a null search path and explicitly includes the schema in every SQL query](https://gitlab.com/gitlab-org/gitlab/-/issues/23211)
 to address [CVE-2018-1058](https://www.postgresql.org/about/news/postgresql-103-968-9512-9417-and-9322-released-1834/).
 
 Since connections are reused with PgBouncer in transaction pooling mode,
diff --git a/doc/security/information_exclusivity.md b/doc/security/information_exclusivity.md
index 0d55881c147..754d5fff843 100644
--- a/doc/security/information_exclusivity.md
+++ b/doc/security/information_exclusivity.md
@@ -24,8 +24,8 @@ limitation.
 You can take steps to prevent unintentional sharing and information
 destruction. This limitation is the reason why only certain people are allowed
 to [add users to a project](../user/project/members/index.md)
-and why only a GitLab administrator can [force push a protected
-branch](../user/project/protected_branches.md).
+and why only a GitLab administrator can 
+[force push a protected branch](../user/project/protected_branches.md).
 
 <!-- ## Troubleshooting
 
diff --git a/doc/subscriptions/gitlab_com/index.md b/doc/subscriptions/gitlab_com/index.md
index a80bae67f04..b81424cddcd 100644
--- a/doc/subscriptions/gitlab_com/index.md
+++ b/doc/subscriptions/gitlab_com/index.md
@@ -299,8 +299,8 @@ for your personal or group namespace. CI/CD minutes are a **one-time purchase**,
 NOTE:
 Free namespaces are subject to a 5GB storage and 10GB transfer [soft limit](https://about.gitlab.com/pricing). Once all storage is available to view in the usage quota workflow, GitLab will automatically enforce the namespace storage limit and the project limit will be removed. This change will be announced separately. The storage and transfer add-on can be purchased to increase the limits.
 
-Projects have a free storage quota of 10 GB. To exceed this quota you must first [purchase one or
-more storage subscription units](#purchase-more-storage-and-transfer). Each unit provides 10 GB of additional
+Projects have a free storage quota of 10 GB. To exceed this quota you must first 
+[purchase one or more storage subscription units](#purchase-more-storage-and-transfer). Each unit provides 10 GB of additional
 storage per namespace. A storage subscription is renewed annually. For more details, see
 [Usage Quotas](../../user/usage_quotas.md).
 
diff --git a/doc/subscriptions/index.md b/doc/subscriptions/index.md
index 4caf69d6015..ed96fbd91ef 100644
--- a/doc/subscriptions/index.md
+++ b/doc/subscriptions/index.md
@@ -109,8 +109,8 @@ Purchases in the Customers Portal require a credit card on record as a payment m
 multiple credit cards to your account, so that purchases for different products are charged to the
 correct card.
 
-If you would like to use an alternative method to pay, please [contact our Sales
-team](https://about.gitlab.com/sales/).
+If you would like to use an alternative method to pay, please 
+[contact our Sales team](https://about.gitlab.com/sales/).
 
 To change your payment method:
 
diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md
index 8d35fd245d5..aacb4f0c97f 100644
--- a/doc/topics/autodevops/stages.md
+++ b/doc/topics/autodevops/stages.md
@@ -458,8 +458,8 @@ To use Auto Deploy on a Kubernetes 1.16+ cluster:
    ```
 
 1. If you have an in-cluster PostgreSQL database installed with
-   `AUTO_DEVOPS_POSTGRES_CHANNEL` set to `1`, follow the [guide to upgrade
-   PostgreSQL](upgrading_postgresql.md).
+   `AUTO_DEVOPS_POSTGRES_CHANNEL` set to `1`, follow the
+   [guide to upgrade PostgreSQL](upgrading_postgresql.md).
 
 1. If you are deploying your application for the first time and are using
    GitLab 12.9 or 12.10, set `AUTO_DEVOPS_POSTGRES_CHANNEL` to `2`.
diff --git a/doc/topics/autodevops/upgrading_postgresql.md b/doc/topics/autodevops/upgrading_postgresql.md
index 258195bb89f..0d8d8cd6579 100644
--- a/doc/topics/autodevops/upgrading_postgresql.md
+++ b/doc/topics/autodevops/upgrading_postgresql.md
@@ -131,8 +131,7 @@ being modified after the database dump is created.
 
 ## Retain persistent volumes
 
-By default the [persistent
-volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
+By default the [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
 used to store the underlying data for PostgreSQL is marked as `Delete`
 when the pods and pod claims that use the volume is deleted.
 
diff --git a/doc/topics/offline/quick_start_guide.md b/doc/topics/offline/quick_start_guide.md
index aa923eb6dc6..353ba094d1e 100644
--- a/doc/topics/offline/quick_start_guide.md
+++ b/doc/topics/offline/quick_start_guide.md
@@ -139,8 +139,7 @@ sudo cp /etc/gitlab/ssl/my-host.internal.crt /etc/gitlab-runner/certs/ca.crt
 
 ## Enabling GitLab Runner
 
-[Following a similar process to the steps for installing our GitLab Runner as a
-Docker service](https://docs.gitlab.com/runner/install/docker.html#docker-image-installation), we must first register our runner:
+[Following a similar process to the steps for installing our GitLab Runner as a Docker service](https://docs.gitlab.com/runner/install/docker.html#install-the-docker-image-and-start-the-container), we must first register our runner:
 
 ```shell
 $ sudo docker run --rm -it -v /etc/gitlab-runner:/etc/gitlab-runner gitlab/gitlab-runner register
diff --git a/doc/topics/release_your_application.md b/doc/topics/release_your_application.md
index 6c94e9e78f9..61ca1468dca 100644
--- a/doc/topics/release_your_application.md
+++ b/doc/topics/release_your_application.md
@@ -30,14 +30,14 @@ to Kubernetes clusters using the [GitLab agent](../user/clusters/agent/install/i
 
 #### GitOps deployments **(PREMIUM)**
 
-With the [GitLab agent for Kubernetes](../user/clusters/agent/install/index.md), you can perform [pull-based
-deployments of Kubernetes manifests](../user/clusters/agent/gitops.md). This provides a scalable, secure, and cloud-native
-approach to manage Kubernetes deployments.
+With the [GitLab agent for Kubernetes](../user/clusters/agent/install/index.md), you can perform 
+[pull-based deployments of Kubernetes manifests](../user/clusters/agent/gitops.md). This provides a scalable, secure, 
+and cloud-native approach to manage Kubernetes deployments.
 
 #### Deploy to Kubernetes from GitLab CI/CD
 
-With the [GitLab agent for Kubernetes](../user/clusters/agent/install/index.md), you can perform [push-based
-deployments](../user/clusters/agent/ci_cd_workflow.md) from GitLab CI/CD. The agent provides
+With the [GitLab agent for Kubernetes](../user/clusters/agent/install/index.md), you can perform 
+[push-based deployments](../user/clusters/agent/ci_cd_workflow.md) from GitLab CI/CD. The agent provides
 a secure and reliable connection between GitLab and your Kubernetes cluster.
 
 ### Deploy to AWS with GitLab CI/CD
diff --git a/doc/update/index.md b/doc/update/index.md
index 6515a9301e4..8eef6037b75 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -41,9 +41,8 @@ There are also instructions when you want to
 
 ### Installation from source
 
-- [Upgrading Community Edition and Enterprise Edition from
-  source](upgrading_from_source.md) - The guidelines for upgrading Community
-  Edition and Enterprise Edition from source.
+- [Upgrading Community Edition and Enterprise Edition from source](upgrading_from_source.md) - 
+  The guidelines for upgrading Community Edition and Enterprise Edition from source.
 - [Patch versions](patch_versions.md) guide includes the steps needed for a
   patch version, such as 13.2.0 to 13.2.1, and apply to both Community and Enterprise
   Editions.
@@ -329,8 +328,8 @@ sudo -u git -H bundle exec rake gitlab:elastic:list_pending_migrations
 ### What do you do if your Advanced Search migrations are stuck?
 
 In GitLab 15.0, an Advanced Search migration named `DeleteOrphanedCommit` can be permanently stuck
-in a pending state across upgrades. This issue [is corrected in
-GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89539).
+in a pending state across upgrades. This issue 
+[is corrected in GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89539).
 
 If you are a self-managed customer who uses GitLab 15.0 with Advanced Search, you will experience performance degradation.
 To clean up the migration, upgrade to 15.1 or later.
@@ -1041,8 +1040,8 @@ In 13.1.0, you must upgrade to either:
 Failure to do so results in internal errors in the Gitaly service in some RPCs due
 to the use of the new `--end-of-options` Git flag.
 
-Additionally, in GitLab 13.1.0, the version of [Rails was upgraded from 6.0.3 to
-6.0.3.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33454).
+Additionally, in GitLab 13.1.0, the version of 
+[Rails was upgraded from 6.0.3 to 6.0.3.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33454).
 The Rails upgrade included a change to CSRF token generation which is
 not backwards-compatible - GitLab servers with the new Rails version
 generate CSRF tokens that are not recognizable by GitLab servers
diff --git a/doc/update/upgrading_from_ce_to_ee.md b/doc/update/upgrading_from_ce_to_ee.md
index b953194b4cf..55561abc009 100644
--- a/doc/update/upgrading_from_ce_to_ee.md
+++ b/doc/update/upgrading_from_ce_to_ee.md
@@ -10,8 +10,7 @@ comments: false
 NOTE:
 In the past we used separate documents for upgrading from
 Community Edition to Enterprise Edition. These documents can be found in the
-[`doc/update` directory of Enterprise Edition's source
-code](https://gitlab.com/gitlab-org/gitlab/-/tree/11-8-stable-ee/doc/update).
+[`doc/update` directory of Enterprise Edition's source code](https://gitlab.com/gitlab-org/gitlab/-/tree/11-8-stable-ee/doc/update).
 
 If you want to upgrade the version only, for example 11.8 to 11.9, *without* changing the
 GitLab edition you are using (Community or Enterprise), see the
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index 8b921f6d0ce..2df11e8f741 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -119,8 +119,8 @@ rm go1.17.10.linux-amd64.tar.gz
 To check you are running the minimum required Git version, see
 [Git versions](../install/installation.md#software-requirements).
 
-From GitLab 13.6, we recommend you use the [Git version provided by
-Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729)
+From GitLab 13.6, we recommend you use the 
+[Git version provided by Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729)
 that:
 
 - Is always at the version required by GitLab.
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index 3cdc6177a4d..ae308925298 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -53,8 +53,8 @@ migrating data. Background migrations are only added in the monthly releases.
 Certain major/minor releases may require a set of background migrations to be
 finished. To guarantee this, such a release processes any remaining jobs
 before continuing the upgrading procedure. While this doesn't require downtime
-(if the above conditions are met) we require that you [wait for background
-migrations to complete](index.md#checking-for-background-migrations-before-upgrading)
+(if the above conditions are met) we require that you 
+[wait for background migrations to complete](index.md#checking-for-background-migrations-before-upgrading)
 between each major/minor release upgrade.
 The time necessary to complete these migrations can be reduced by
 increasing the number of Sidekiq workers that can process jobs in the
diff --git a/doc/user/admin_area/review_abuse_reports.md b/doc/user/admin_area/review_abuse_reports.md
index ec8e6f2dda4..a5e7fcb1b8e 100644
--- a/doc/user/admin_area/review_abuse_reports.md
+++ b/doc/user/admin_area/review_abuse_reports.md
@@ -26,8 +26,8 @@ The notification email address can also be set and retrieved
 
 ## Reporting abuse
 
-To find out more about reporting abuse, see [abuse reports user
-documentation](../report_abuse.md).
+To find out more about reporting abuse, see 
+[abuse reports user documentation](../report_abuse.md).
 
 ## Resolving abuse reports
 
diff --git a/doc/user/application_security/dast/checks/16.7.md b/doc/user/application_security/dast/checks/16.7.md
index a02fb3a451f..2e6607575db 100644
--- a/doc/user/application_security/dast/checks/16.7.md
+++ b/doc/user/application_security/dast/checks/16.7.md
@@ -25,8 +25,8 @@ Only three directives are applicable for the `Strict-Transport-Security` header.
 Note that invalid directives, or the `Strict-Transport-Security` header appearing more than once (if the values are
 different) is considered invalid.
 
-Prior to adding to this security configuration to your website, it is recommended you review the hstspreload.org [Deployment
-Recommendations](https://hstspreload.org/#deployment-recommendations).
+Prior to adding to this security configuration to your website, it is recommended you review the hstspreload.org 
+[Deployment Recommendations](https://hstspreload.org/#deployment-recommendations).
 
 ## Details
 
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index f8aa2e3d1c6..e745f12fe31 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -995,8 +995,7 @@ An on-demand scan can be run in active or passive mode:
 
 - _Passive mode_ is the default and runs a ZAP Baseline Scan.
 - _Active mode_ runs a ZAP Full Scan which is potentially harmful to the site being scanned. To
-  minimize the risk of accidental damage, running an active scan requires a [validated site
-  profile](#site-profile-validation).
+  minimize the risk of accidental damage, running an active scan requires a [validated site profile](#site-profile-validation).
 
 ### View on-demand DAST scans
 
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index e3a419ea771..f578c5eca00 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -149,8 +149,8 @@ base address for Docker images. You can override this for most scanners by setti
 
 The [Container Scanning](container_scanning/index.md) analyzer is an exception, and it
 does not use the `SECURE_ANALYZERS_PREFIX` variable. To override its Docker image, see
-the instructions for [Running container scanning in an offline
-environment](container_scanning/index.md#running-container-scanning-in-an-offline-environment).
+the instructions for 
+[Running container scanning in an offline environment](container_scanning/index.md#running-container-scanning-in-an-offline-environment).
 
 ### Use security scanning tools with merge request pipelines
 
diff --git a/doc/user/clusters/agent/ci_cd_workflow.md b/doc/user/clusters/agent/ci_cd_workflow.md
index dce02a72300..d383cf3d7cb 100644
--- a/doc/user/clusters/agent/ci_cd_workflow.md
+++ b/doc/user/clusters/agent/ci_cd_workflow.md
@@ -127,8 +127,8 @@ Run `kubectl config get-contexts`.
 
 ### Environments with both certificate-based and agent-based connections
 
-When you deploy to an environment that has both a [certificate-based
-cluster](../../infrastructure/clusters/index.md) (deprecated) and an agent connection:
+When you deploy to an environment that has both a 
+[certificate-based cluster](../../infrastructure/clusters/index.md) (deprecated) and an agent connection:
 
 - The certificate-based cluster's context is called `gitlab-deploy`. This context
   is always selected by default.
diff --git a/doc/user/clusters/environments.md b/doc/user/clusters/environments.md
index b7732a7abf8..cf71729b517 100644
--- a/doc/user/clusters/environments.md
+++ b/doc/user/clusters/environments.md
@@ -33,8 +33,8 @@ With cluster environments, you can gain insight into:
 
 ![Cluster environments page](img/cluster_environments_table_v12_3.png)
 
-Access to cluster environments is restricted to [group maintainers and
-owners](../permissions.md#group-members-permissions)
+Access to cluster environments is restricted to 
+[group maintainers and owners](../permissions.md#group-members-permissions)
 
 ## Usage
 
diff --git a/doc/user/clusters/management_project.md b/doc/user/clusters/management_project.md
index d59edb1e2c2..361276194b0 100644
--- a/doc/user/clusters/management_project.md
+++ b/doc/user/clusters/management_project.md
@@ -81,8 +81,7 @@ configure cluster:
 
 ### Setting the environment scope
 
-[Environment
-scopes](../project/clusters/multiple_kubernetes_clusters.md#setting-the-environment-scope)
+[Environment scopes](../project/clusters/multiple_kubernetes_clusters.md#setting-the-environment-scope)
 are usable when associating multiple clusters to the same management
 project.
 
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index 707669a3145..c265cbaf3f9 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -336,8 +336,8 @@ documentation.
 
 When a request is rate limited, GitLab responds with a `429` status
 code. The client should wait before attempting the request again. There
-are also informational headers with this response detailed in [rate
-limiting responses](#rate-limiting-responses).
+are also informational headers with this response detailed in 
+[rate limiting responses](#rate-limiting-responses).
 
 The following table describes the rate limits for GitLab.com, both before and
 after the limits change in January, 2021:
@@ -358,9 +358,9 @@ after the limits change in January, 2021:
 | **Pipeline creation** requests (for a given **project, user, and commit**) |                               | **25** requests per minute              |
 | **Alert integration endpoint** requests (for a given **project**)          |                               | **3600** requests per hour |
 
-More details are available on the rate limits for [protected
-paths](#protected-paths-throttle) and [raw
-endpoints](../../user/admin_area/settings/rate_limits_on_raw_endpoints.md).
+More details are available on the rate limits for 
+[protected paths](#protected-paths-throttle) and 
+[raw endpoints](../../user/admin_area/settings/rate_limits_on_raw_endpoints.md).
 
 GitLab can rate-limit requests at several layers. The rate limits listed here
 are configured in the application. These limits are the most
diff --git a/doc/user/infrastructure/clusters/manage/management_project_applications/certmanager.md b/doc/user/infrastructure/clusters/manage/management_project_applications/certmanager.md
index 5ad1fb81a39..c3f54d2a724 100644
--- a/doc/user/infrastructure/clusters/manage/management_project_applications/certmanager.md
+++ b/doc/user/infrastructure/clusters/manage/management_project_applications/certmanager.md
@@ -19,18 +19,16 @@ uncomment this line from your `helmfile.yaml`:
 ```
 
 NOTE:
-If your Kubernetes version is earlier than 1.20 and you are [migrating from GitLab
-Managed Apps to a cluster management
-project](../../../../clusters/migrating_from_gma_to_project_template.md), then
-you can instead use `- path: applications/cert-manager-legacy/helmfile.yaml` to
+If your Kubernetes version is earlier than 1.20 and you are 
+[migrating from GitLab Managed Apps to a cluster management project](../../../../clusters/migrating_from_gma_to_project_template.md), 
+then you can instead use `- path: applications/cert-manager-legacy/helmfile.yaml` to
 take over an existing release of cert-manager v0.10.
 
 cert-manager:
 
 - Is installed by default into the `gitlab-managed-apps` namespace of your cluster.
 - Includes a
-  [Let's Encrypt
-  `ClusterIssuer`](https://cert-manager.io/docs/configuration/acme/) enabled by
+  [Let's Encrypt `ClusterIssuer`](https://cert-manager.io/docs/configuration/acme/) enabled by
   default. In the `certmanager-issuer` release, the issuer requires a valid email address
   for `letsEncryptClusterIssuer.email`. Let's Encrypt uses this email address to
   contact you about expiring certificates and issues related to your account.
diff --git a/doc/user/project/canary_deployments.md b/doc/user/project/canary_deployments.md
index a76517a7341..f8494116655 100644
--- a/doc/user/project/canary_deployments.md
+++ b/doc/user/project/canary_deployments.md
@@ -38,9 +38,9 @@ want to make sure the performance stays the same, or improves. Developers need
 to be careful when using canaries with user-facing changes, because by default,
 requests from the same user are randomly distributed between canary and
 non-canary pods, which could result in confusion or even errors. If needed, you
-may want to consider [setting `service.spec.sessionAffinity` to `ClientIP` in
-your Kubernetes service definitions](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies), but that is beyond the scope of
-this document.
+may want to consider 
+[setting `service.spec.sessionAffinity` to `ClientIP` in your Kubernetes service definitions](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies), 
+but that is beyond the scope of this document.
 
 ## Advanced traffic control with Canary Ingress
 
diff --git a/doc/user/project/clusters/add_gke_clusters.md b/doc/user/project/clusters/add_gke_clusters.md
index 2e1c8766ae3..71b65867c4a 100644
--- a/doc/user/project/clusters/add_gke_clusters.md
+++ b/doc/user/project/clusters/add_gke_clusters.md
@@ -51,8 +51,8 @@ Note the following:
   cluster's pod address IP range is set to `/16` instead of the regular `/14`. `/16` is a CIDR
   notation.
 - GitLab requires basic authentication enabled and a client certificate issued for the cluster to
-  set up an [initial service account](cluster_access.md). In [GitLab versions
-  11.10 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58208), the cluster creation process
+  set up an [initial service account](cluster_access.md). In 
+  [GitLab versions 11.10 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58208), the cluster creation process
   explicitly requests GKE to create clusters with basic authentication enabled and a client
   certificate.
 
diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md
index a90ffbe5796..41afbdada6b 100644
--- a/doc/user/project/deploy_boards.md
+++ b/doc/user/project/deploy_boards.md
@@ -116,8 +116,8 @@ To display the deploy boards for a specific [environment](../../ci/environments/
    Kubernetes.
 
    NOTE:
-   Matching based on the Kubernetes `app` label was removed in [GitLab
-   12.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14020).
+   Matching based on the Kubernetes `app` label was removed in 
+   [GitLab 12.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14020).
    To migrate, please apply the required annotations (see above) and
    re-deploy your application. If you are using Auto DevOps, this will
    be done automatically and no action is necessary.
diff --git a/doc/user/project/deploy_keys/index.md b/doc/user/project/deploy_keys/index.md
index c997d93b71b..a9f19d27416 100644
--- a/doc/user/project/deploy_keys/index.md
+++ b/doc/user/project/deploy_keys/index.md
@@ -146,8 +146,8 @@ What happens to the deploy key when it is disabled depends on the following:
 
 ### Deploy key cannot push to a protected branch
 
-There are a few scenarios where a deploy key will fail to push to a [protected
-branch](../protected_branches.md).
+There are a few scenarios where a deploy key will fail to push to a
+[protected branch](../protected_branches.md).
 
 - The owner associated to a deploy key does not have access to the protected branch.
 - The owner associated to a deploy key does not have [membership](../members/index.md) to the project of the protected branch.
diff --git a/doc/user/project/import/clearcase.md b/doc/user/project/import/clearcase.md
index 867477c83b2..d9ad0c57d79 100644
--- a/doc/user/project/import/clearcase.md
+++ b/doc/user/project/import/clearcase.md
@@ -11,8 +11,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 tools developed by IBM which also include a centralized version control system
 similar to Git.
 
-A good read of ClearCase's basic concepts is can be found in this [StackOverflow
-post](https://stackoverflow.com/a/645771/974710).
+A good read of ClearCase's basic concepts is can be found in this 
+[StackOverflow post](https://stackoverflow.com/a/645771/974710).
 
 The following table illustrates the main differences between ClearCase and Git:
 
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 b0ae1b7d1e0..4e948bcc9ae 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
@@ -46,8 +46,8 @@ To purge files from a GitLab repository:
    [`git-sizer`](https://github.com/github/git-sizer#getting-started)
    using a supported package manager or from source.
 
-1. Generate a fresh [export from the
-   project](../settings/import_export.html#export-a-project-and-its-data) and download it.
+1. Generate a fresh 
+   [export from the project](../settings/import_export.md#export-a-project-and-its-data) and download it.
    This project export contains a backup copy of your repository *and* refs
    we can use to purge files from your repository.
 
diff --git a/lib/gitlab/ci/runner_releases.rb b/lib/gitlab/ci/runner_releases.rb
index 31a537f1b61..dab24bfd501 100644
--- a/lib/gitlab/ci/runner_releases.rb
+++ b/lib/gitlab/ci/runner_releases.rb
@@ -36,6 +36,9 @@ module Gitlab
 
           reset_backoff!
           extract_releases(response)
+        rescue Errno::ETIMEDOUT
+          @backoff_expire_time = next_backoff.from_now
+          break nil
         end
       end
 
diff --git a/lib/gitlab/usage_data_counters/hll_redis_counter.rb b/lib/gitlab/usage_data_counters/hll_redis_counter.rb
index 84f4a873818..a5db8ba4dcc 100644
--- a/lib/gitlab/usage_data_counters/hll_redis_counter.rb
+++ b/lib/gitlab/usage_data_counters/hll_redis_counter.rb
@@ -168,11 +168,7 @@ module Gitlab
         private
 
         def categories_pending_migration
-          if ::Feature.enabled?(:use_redis_hll_instrumentation_classes)
-            (categories - categories_collected_from_metrics_definitions)
-          else
-            categories
-          end
+          (categories - categories_collected_from_metrics_definitions)
         end
 
         def track(values, event_name, context: '', time: Time.zone.now)
diff --git a/qa/qa/specs/features/browser_ui/2_plan/issue/create_issue_spec.rb b/qa/qa/specs/features/browser_ui/2_plan/issue/create_issue_spec.rb
index b8f1824126d..ed271533f87 100644
--- a/qa/qa/specs/features/browser_ui/2_plan/issue/create_issue_spec.rb
+++ b/qa/qa/specs/features/browser_ui/2_plan/issue/create_issue_spec.rb
@@ -1,11 +1,7 @@
 # frozen_string_literal: true
 
 module QA
-  RSpec.describe(
-    'Plan',
-    :smoke,
-    quarantine: { issue: 'https://gitlab.com/gitlab-com/gl-infra/production/-/issues/7099', type: :investigating, only: { subdomain: 'pre' } }
-  ) do
+  RSpec.describe 'Plan', :smoke do
     describe 'Issue creation' do
       let(:project) { Resource::Project.fabricate_via_api! }
       let(:closed_issue) { Resource::Issue.fabricate_via_api! { |issue| issue.project = project } }
diff --git a/spec/frontend/work_items/components/work_item_assignees_spec.js b/spec/frontend/work_items/components/work_item_assignees_spec.js
index 547034bad45..450d9cff963 100644
--- a/spec/frontend/work_items/components/work_item_assignees_spec.js
+++ b/spec/frontend/work_items/components/work_item_assignees_spec.js
@@ -10,9 +10,10 @@ import { DEFAULT_DEBOUNCE_AND_THROTTLE_MS } from '~/lib/utils/constants';
 import userSearchQuery from '~/graphql_shared/queries/users_search.query.graphql';
 import currentUserQuery from '~/graphql_shared/queries/current_user.query.graphql';
 import workItemQuery from '~/work_items/graphql/work_item.query.graphql';
+import updateWorkItemMutation from '~/work_items/graphql/update_work_item.mutation.graphql';
 import WorkItemAssignees from '~/work_items/components/work_item_assignees.vue';
 import { i18n, TASK_TYPE_NAME, TRACKING_CATEGORY_SHOW } from '~/work_items/constants';
-import { temporaryConfig, resolvers } from '~/work_items/graphql/provider';
+import { temporaryConfig } from '~/work_items/graphql/provider';
 import {
   projectMembersResponseWithCurrentUser,
   mockAssignees,
@@ -20,6 +21,7 @@ import {
   currentUserResponse,
   currentUserNullResponse,
   projectMembersResponseWithoutCurrentUser,
+  updateWorkItemMutationResponse,
 } from '../mock_data';
 
 Vue.use(VueApollo);
@@ -43,6 +45,9 @@ describe('WorkItemAssignees component', () => {
     .mockResolvedValue(projectMembersResponseWithCurrentUser);
   const successCurrentUserQueryHandler = jest.fn().mockResolvedValue(currentUserResponse);
   const noCurrentUserQueryHandler = jest.fn().mockResolvedValue(currentUserNullResponse);
+  const successUpdateWorkItemMutationHandler = jest
+    .fn()
+    .mockResolvedValue(updateWorkItemMutationResponse);
 
   const errorHandler = jest.fn().mockRejectedValue('Houston, we have a problem');
 
@@ -50,6 +55,7 @@ describe('WorkItemAssignees component', () => {
     assignees = mockAssignees,
     searchQueryHandler = successSearchQueryHandler,
     currentUserQueryHandler = successCurrentUserQueryHandler,
+    updateWorkItemMutationHandler = successUpdateWorkItemMutationHandler,
     allowsMultipleAssignees = true,
     canUpdate = true,
   } = {}) => {
@@ -57,8 +63,9 @@ describe('WorkItemAssignees component', () => {
       [
         [userSearchQuery, searchQueryHandler],
         [currentUserQuery, currentUserQueryHandler],
+        [updateWorkItemMutation, updateWorkItemMutationHandler],
       ],
-      resolvers,
+      {},
       {
         typePolicies: temporaryConfig.cacheConfig.typePolicies,
       },
@@ -120,15 +127,6 @@ describe('WorkItemAssignees component', () => {
     expect(findTokenSelector().element.contains(document.activeElement)).toBe(true);
   });
 
-  it('calls a mutation on clicking outside the token selector', async () => {
-    createComponent();
-    findTokenSelector().vm.$emit('input', [mockAssignees[0]]);
-    findTokenSelector().vm.$emit('blur', new FocusEvent({ relatedTarget: null }));
-    await waitForPromises();
-
-    expect(findTokenSelector().props('selectedTokens')).toEqual([mockAssignees[0]]);
-  });
-
   it('passes `false` to `viewOnly` token selector prop if user can update assignees', () => {
     createComponent();
 
@@ -141,6 +139,36 @@ describe('WorkItemAssignees component', () => {
     expect(findTokenSelector().props('viewOnly')).toBe(true);
   });
 
+  describe('when clicking outside the token selector', () => {
+    function arrange(args) {
+      createComponent(args);
+      findTokenSelector().vm.$emit('input', [mockAssignees[0]]);
+      findTokenSelector().vm.$emit('blur', new FocusEvent({ relatedTarget: null }));
+    }
+
+    it('calls a mutation with correct variables', () => {
+      arrange({ assignees: [] });
+
+      expect(successUpdateWorkItemMutationHandler).toHaveBeenCalledWith({
+        input: {
+          assigneesWidget: { assigneeIds: [mockAssignees[0].id] },
+          id: 'gid://gitlab/WorkItem/1',
+        },
+      });
+    });
+
+    it('emits an error and resets assignees if mutation was rejected', async () => {
+      arrange({ updateWorkItemMutationHandler: errorHandler, assignees: [mockAssignees[1]] });
+
+      await waitForPromises();
+
+      expect(wrapper.emitted('error')).toEqual([[i18n.updateError]]);
+      expect(findTokenSelector().props('selectedTokens')).toEqual([
+        { ...mockAssignees[1], class: expect.anything() },
+      ]);
+    });
+  });
+
   describe('when searching for users', () => {
     beforeEach(() => {
       createComponent();
@@ -225,6 +253,18 @@ describe('WorkItemAssignees component', () => {
     expect(wrapper.emitted('error')).toEqual([[i18n.fetchError]]);
   });
 
+  it('updates localAssignees when assignees prop is updated', async () => {
+    createComponent({ assignees: [] });
+
+    expect(findTokenSelector().props('selectedTokens')).toEqual([]);
+
+    await wrapper.setProps({ assignees: [mockAssignees[0]] });
+
+    expect(findTokenSelector().props('selectedTokens')).toEqual([
+      { ...mockAssignees[0], class: expect.anything() },
+    ]);
+  });
+
   describe('when assigning to current user', () => {
     it('does not show `Assign myself` button if current user is loading', () => {
       createComponent();
@@ -261,23 +301,23 @@ describe('WorkItemAssignees component', () => {
       expect(findAssignSelfButton().exists()).toBe(true);
     });
 
-    it('calls update work item assignees mutation with current user as a variable on button click', () => {
-      // TODO: replace this test as soon as we have a real mutation implemented
-      jest.spyOn(wrapper.vm.$apollo, 'mutate').mockImplementation(jest.fn());
-
+    it('calls update work item assignees mutation with current user as a variable on button click', async () => {
+      const { currentUser } = currentUserResponse.data;
       findTokenSelector().trigger('mouseover');
       findAssignSelfButton().vm.$emit('click', new MouseEvent('click'));
+      await nextTick();
 
-      expect(wrapper.vm.$apollo.mutate).toHaveBeenCalledWith(
-        expect.objectContaining({
-          variables: {
-            input: {
-              assignees: [stripTypenames(currentUserResponse.data.currentUser)],
-              id: workItemId,
-            },
+      expect(findTokenSelector().props('selectedTokens')).toMatchObject([
+        stripTypenames(currentUser),
+      ]);
+      expect(successUpdateWorkItemMutationHandler).toHaveBeenCalledWith({
+        input: {
+          id: workItemId,
+          assigneesWidget: {
+            assigneeIds: [currentUser.id],
           },
-        }),
-      );
+        },
+      });
     });
   });
 
@@ -303,9 +343,10 @@ describe('WorkItemAssignees component', () => {
     });
 
     it('adds current user to the top of dropdown items', () => {
-      expect(findTokenSelector().props('dropdownItems')[0]).toEqual(
-        stripTypenames(currentUserResponse.data.currentUser),
-      );
+      expect(findTokenSelector().props('dropdownItems')[0]).toEqual({
+        ...stripTypenames(currentUserResponse.data.currentUser),
+        class: expect.anything(),
+      });
     });
 
     it('does not add current user if search is not empty', async () => {
diff --git a/spec/frontend/work_items/mock_data.js b/spec/frontend/work_items/mock_data.js
index c7105533ea7..a04f5a523fe 100644
--- a/spec/frontend/work_items/mock_data.js
+++ b/spec/frontend/work_items/mock_data.js
@@ -101,6 +101,14 @@ export const updateWorkItemMutationResponse = {
               ],
             },
           },
+          {
+            __typename: 'WorkItemWidgetAssignees',
+            type: 'ASSIGNEES',
+            allowsMultipleAssignees: true,
+            assignees: {
+              nodes: [mockAssignees[0]],
+            },
+          },
         ],
       },
     },
diff --git a/spec/lib/gitlab/ci/runner_releases_spec.rb b/spec/lib/gitlab/ci/runner_releases_spec.rb
index b47e94400c5..ad1e9b12b8a 100644
--- a/spec/lib/gitlab/ci/runner_releases_spec.rb
+++ b/spec/lib/gitlab/ci/runner_releases_spec.rb
@@ -77,7 +77,8 @@ RSpec.describe Gitlab::Ci::RunnerReleases do
         allow(Gitlab::HTTP).to receive(:get).with(runner_releases_url, anything) do
           http_call_timestamp_offsets << Time.now.utc - start_time
 
-          raise Net::OpenTimeout if opts&.dig(:raise_timeout)
+          err_class = opts&.dig(:raise_error)
+          raise err_class if err_class
 
           mock_http_response(response)
         end
@@ -118,7 +119,8 @@ RSpec.describe Gitlab::Ci::RunnerReleases do
       let(:expected_releases_by_minor) { nil }
 
       it_behaves_like 'requests that follow cache status', 5.seconds
-      it_behaves_like 'a service implementing exponential backoff', raise_timeout: true
+      it_behaves_like 'a service implementing exponential backoff', raise_error: Net::OpenTimeout
+      it_behaves_like 'a service implementing exponential backoff', raise_error: Errno::ETIMEDOUT
     end
 
     context 'when response is nil' do
diff --git a/spec/lib/gitlab/usage_data_counters/hll_redis_counter_spec.rb b/spec/lib/gitlab/usage_data_counters/hll_redis_counter_spec.rb
index 8b4bd8a82cd..e0b334cb5af 100644
--- a/spec/lib/gitlab/usage_data_counters/hll_redis_counter_spec.rb
+++ b/spec/lib/gitlab/usage_data_counters/hll_redis_counter_spec.rb
@@ -77,22 +77,9 @@ RSpec.describe Gitlab::UsageDataCounters::HLLRedisCounter, :clean_gitlab_redis_s
     end
 
     describe '.unique_events_data' do
-      context 'with use_redis_hll_instrumentation_classes feature enabled' do
-        it 'does not include instrumented categories' do
-          stub_feature_flags(use_redis_hll_instrumentation_classes: true)
-
-          expect(described_class.unique_events_data.keys)
-            .not_to include(*described_class.categories_collected_from_metrics_definitions)
-        end
-      end
-
-      context 'with use_redis_hll_instrumentation_classes feature disabled' do
-        it 'includes instrumented categories' do
-          stub_feature_flags(use_redis_hll_instrumentation_classes: false)
-
-          expect(described_class.unique_events_data.keys)
-            .to include(*described_class.categories_collected_from_metrics_definitions)
-        end
+      it 'does not include instrumented categories' do
+        expect(described_class.unique_events_data.keys)
+          .not_to include(*described_class.categories_collected_from_metrics_definitions)
       end
     end
   end
diff --git a/spec/lib/gitlab/usage_data_spec.rb b/spec/lib/gitlab/usage_data_spec.rb
index 6eb00053b17..692b6483149 100644
--- a/spec/lib/gitlab/usage_data_spec.rb
+++ b/spec/lib/gitlab/usage_data_spec.rb
@@ -1203,12 +1203,14 @@ RSpec.describe Gitlab::UsageData, :aggregate_failures do
   describe 'redis_hll_counters' do
     subject { described_class.redis_hll_counters }
 
-    let(:categories) { ::Gitlab::UsageDataCounters::HLLRedisCounter.categories }
+    let(:migrated_categories) do
+      ::Gitlab::UsageDataCounters::HLLRedisCounter.categories_collected_from_metrics_definitions
+    end
 
+    let(:categories) { ::Gitlab::UsageDataCounters::HLLRedisCounter.categories - migrated_categories }
     let(:ignored_metrics) { ["i_package_composer_deploy_token_weekly"] }
 
     it 'has all known_events' do
-      stub_feature_flags(use_redis_hll_instrumentation_classes: false)
       expect(subject).to have_key(:redis_hll_counters)
 
       expect(subject[:redis_hll_counters].keys).to match_array(categories)
diff --git a/spec/models/ci/pipeline_spec.rb b/spec/models/ci/pipeline_spec.rb
index 7264e48c481..2f033559b0c 100644
--- a/spec/models/ci/pipeline_spec.rb
+++ b/spec/models/ci/pipeline_spec.rb
@@ -3060,19 +3060,7 @@ RSpec.describe Ci::Pipeline, :mailer, factory_default: :keep do
       end
     end
 
-    context 'with retries' do
-      context 'when feature ci_parent_pipeline_cancels_children is disabled' do
-        before do
-          stub_feature_flags(ci_parent_pipeline_cancels_children: false)
-        end
-
-        it_behaves_like 'retries'
-      end
-
-      context 'when feature ci_parent_pipeline_cancels_children is enabled' do
-        it_behaves_like 'retries'
-      end
-    end
+    it_behaves_like 'retries'
 
     context 'when auto canceled' do
       let!(:canceled_by) { create(:ci_empty_pipeline) }
@@ -3211,23 +3199,6 @@ RSpec.describe Ci::Pipeline, :mailer, factory_default: :keep do
           expect(latest_status_for_child).to eq %w(failed)
           expect(latest_status).to eq %w(canceled)
         end
-
-        context 'when feature ci_parent_pipeline_cancels_children is disabled' do
-          before do
-            stub_feature_flags(ci_parent_pipeline_cancels_children: false)
-          end
-
-          it 'does not cancel child pipeline builds' do
-            create(:ci_build, :created, pipeline: child_pipeline)
-            create(:ci_build, :running, pipeline: child_pipeline)
-
-            cancel_running
-
-            latest_status_for_child = child_pipeline.statuses.pluck(:status)
-            expect(latest_status_for_child).not_to include('canceled')
-            expect(latest_status).to eq %w(canceled)
-          end
-        end
       end
 
       context 'when cascade_to_children is false' do
@@ -3255,23 +3226,6 @@ RSpec.describe Ci::Pipeline, :mailer, factory_default: :keep do
           expect(latest_status_for_child).to eq %w(failed)
           expect(latest_status).to eq %w(canceled)
         end
-
-        context 'when feature ci_parent_pipeline_cancels_children is disabled' do
-          before do
-            stub_feature_flags(ci_parent_pipeline_cancels_children: false)
-          end
-
-          it 'cancels parent but not children pipeline builds' do
-            create(:ci_build, :created, pipeline: child_pipeline)
-            create(:ci_build, :running, pipeline: child_pipeline)
-
-            cancel_running
-
-            latest_status_for_child = child_pipeline.statuses.pluck(:status)
-            expect(latest_status_for_child).not_to include('canceled')
-            expect(latest_status).to eq %w(canceled)
-          end
-        end
       end
     end
   end