diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 11790e3a58ef99013a38d033819278fd6daccd3e..7c597bd5f0fb159f1efee2f4f26acc1a7013cd07 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -208,7 +208,7 @@ Events visible in Audit Events views until more events are logged.
 
 ### "Deleted User" events
 
-Audit events can be created for a user after the user is deleted. The user name associated with the event is set to 
+Audit events can be created for a user after the user is deleted. The user name associated with the event is set to
 "Deleted User" because the actual user name is unknowable. For example, if a deleted user's access to a project is
 removed automatically due to expiration, the audit event is created for "Deleted User". We are [investigating](https://gitlab.com/gitlab-org/gitlab/-/issues/343933)
 whether this is avoidable.
diff --git a/doc/administration/auth/ldap/index.md b/doc/administration/auth/ldap/index.md
index d2a783972dcedc8832157974643de33bbd29c288..f551c36278412646dba1718a1340aeed6db3d699 100644
--- a/doc/administration/auth/ldap/index.md
+++ b/doc/administration/auth/ldap/index.md
@@ -23,7 +23,7 @@ Users added through LDAP:
 
 - Take a [licensed seat](../../../subscriptions/self_managed/index.md#billable-users).
 - Can authenticate with Git using either their GitLab username or their email and LDAP password,
-  even if password authentication for Git 
+  even if password authentication for Git
   [is disabled](../../../user/admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
 
 The LDAP DN is associated with existing GitLab users when:
@@ -41,7 +41,7 @@ If an existing GitLab user wants to enable LDAP sign-in for themselves, they sho
 
 GitLab has multiple mechanisms to verify a user is still active in LDAP. If the user is no longer active in
 LDAP, they are placed in an `ldap_blocked` status and are signed out. They are unable to sign in using any authentication provider until they are
-reactivated in LDAP. 
+reactivated in LDAP.
 
 Users are considered inactive in LDAP when they:
 
diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index 0f5f60fcd8e45c502a64895f47a0967b2df94416..a7a6c5056b20959ef8523020376490e32470dd61 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -68,7 +68,7 @@ a single URL used by all Geo sites, including the primary.
    In the Geo administration page of the **primary** site, edit each Geo secondary that
    is using the secondary proxying and set the `URL` field to the single URL.
    Make sure the primary site is also using this URL.
-   
+
 ## Disable Geo proxying
 
 You can disable the secondary proxying on each Geo site, separately, by following these steps with Omnibus-based packages:
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md
index 942bc0af8dd49b7f9d5616f200f64dd97bde116b..12dd7e459bff57ace293732f7feb0a4b847bdbcd 100644
--- a/doc/administration/instance_limits.md
+++ b/doc/administration/instance_limits.md
@@ -551,7 +551,7 @@ Plan.default.actual_limits.update!(pages_file_entries: 100)
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321368) in GitLab 13.12. Disabled by default.
 > - Enabled on GitLab.com in GitLab 14.3.
 > - Enabled on self-managed in GitLab 14.4.
-> - Feature flag `ci_runner_limits` removed in GitLab 14.4. 
+> - Feature flag `ci_runner_limits` removed in GitLab 14.4.
 > - Feature flag `ci_runner_limits_override` removed in GitLab 14.6.
 
 The total number of registered runners is limited at the group and project levels. Each time a new runner is registered,
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index a85f678fe95b46ed61588633cf1446d2b15ae5e1..f33d494f63854878fce7bc473e2686fe230b5934 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -101,10 +101,10 @@ To look up a project's hash path using a Rails console:
 
 #### From hashed path to project name
 
-Administrators can look up a project's name from its hashed storage path using: 
+Administrators can look up a project's name from its hashed storage path using:
 
 - A Rails console.
-- The `config` file in the `*.git` directory. 
+- The `config` file in the `*.git` directory.
 
 To look up a project's name using the Rails console:
 
diff --git a/doc/api/members.md b/doc/api/members.md
index 51f7b74f110d4271261d210714d1b52aed609f9f..2e2b403eea1ff6d601f94bded529445525525ae6 100644
--- a/doc/api/members.md
+++ b/doc/api/members.md
@@ -596,9 +596,9 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://git
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/:id/members/:user_id"
 ```
 
-## Approve a member for a group 
+## Approve a member for a group
 
-Approves a pending user for a group and its subgroups and projects. 
+Approves a pending user for a group and its subgroups and projects.
 
 ```plaintext
 PUT /groups/:id/members/:user_id/approve
@@ -615,7 +615,7 @@ Example request:
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/:id/members/:user_id/approve"
 ```
 
-## Approve all pending members for a group 
+## Approve all pending members for a group
 
 Approves all pending users for a group and its subgroups and projects.
 
diff --git a/doc/ci/git_submodules.md b/doc/ci/git_submodules.md
index dc5faf0188eef3ce9c05d809abe31ab3282155db..2a002b8fb9f609e2f8f74f181de75ba287582a07 100644
--- a/doc/ci/git_submodules.md
+++ b/doc/ci/git_submodules.md
@@ -59,7 +59,7 @@ To make submodules work correctly in CI/CD jobs:
    variables:
      GIT_SUBMODULE_STRATEGY: recursive
    ```
-   
+
 If you use the [`CI_JOB_TOKEN`](jobs/ci_job_token.md) to clone a submodule in a
 pipeline job, the user executing the job must be assigned to a role that has
 [permission](../user/permissions.md#gitlab-cicd-permissions) to trigger a pipeline
diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md
index be267ec1da15054b5f6706a115065db2cb3668e8..f9e4f3fbdea4178207954c49a58ad58d520a0a4b 100644
--- a/doc/ci/pipelines/merge_trains.md
+++ b/doc/ci/pipelines/merge_trains.md
@@ -39,7 +39,7 @@ If the pipeline for the merge request at the front of the train completes succes
 the changes are merged into the target branch, and the other pipelines continue to
 run.
 
-To add a merge request to a merge train, you need [permissions](../../user/permissions.md) to merge or push to the 
+To add a merge request to a merge train, you need [permissions](../../user/permissions.md) to merge or push to the
 target branch.
 
 Each merge train can run a maximum of **twenty** pipelines in parallel.
diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md
index 571d2f353d404035023638691b558c434cb19ba4..0e8e828946466850dac65d8f53d0b7bcd61b53b6 100644
--- a/doc/development/adding_database_indexes.md
+++ b/doc/development/adding_database_indexes.md
@@ -317,11 +317,11 @@ end
 
 You must test the database index changes locally before creating a merge request.
 
-### Verify indexes created asynchronously 
+### Verify indexes created asynchronously
 
 Use the asynchronous index helpers on your local environment to test changes for creating an index:
 
 1. Enable the feature flags by running `Feature.enable(:database_async_index_creation)` and `Feature.enable(:database_reindexing)` in the Rails console.
 1. Run `bundle exec rails db:migrate` so that it creates an entry in the `postgres_async_indexes` table.
 1. Run `bundle exec rails gitlab:db:reindex` so that the index is created asynchronously.
-1. To verify the index, open the PostgreSQL console using the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/postgresql.md) command `gdk psql` and run the command `\d <index_name>` to check that your newly created index exists. 
+1. To verify the index, open the PostgreSQL console using the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/postgresql.md) command `gdk psql` and run the command `\d <index_name>` to check that your newly created index exists.
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 82fd62d8d796e57f6e2d12606fcce157d69d8095..cc6997e1a2050dd6c76e4638677f4cde90a12cb6 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -100,7 +100,7 @@ request is as follows:
    There isn't a way to know anything about our customers' data on their
    [self-managed instances](../../subscriptions/self_managed/index.md), so keep
    that in mind for any data implications with your merge request.
-   
+
 1. Merge requests **must** adhere to the [merge request performance guidelines](../merge_request_performance_guidelines.md).
 1. For tests that use Capybara, read
    [how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara).
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 5d5d37e0398667f51fe952c2b04db59d7052a84c..ab808e6f1b7fb402fcd0967d31bb7728c2fdd39e 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -73,7 +73,7 @@ component, is that you avoid the need to create a fixture or an HTML element in
 ##### provide/inject
 
 Vue supports dependency injection through [provide/inject](https://vuejs.org/v2/api/#provide-inject).
-In the component the `inject` configuration accesses the values `provide` passes down. 
+In the component the `inject` configuration accesses the values `provide` passes down.
 This example of a Vue app initialization shows how the `provide` configuration passes a value from HAML to the component:
 
 ```javascript
diff --git a/doc/development/fe_guide/vue3_migration.md b/doc/development/fe_guide/vue3_migration.md
index c6f480deb223f525585653c1b5c71234de021e8a..2b783eb21b780b9ae79184d2085aeb2a1e1d9568 100644
--- a/doc/development/fe_guide/vue3_migration.md
+++ b/doc/development/fe_guide/vue3_migration.md
@@ -31,7 +31,7 @@ Component's computed properties / methods or external helpers.
 
 **When to use**
 
-If you are in a Vue app that doesn't use any event hub, try to avoid adding a new one unless absolutely necessary. For example, if you need a child component to react to its parent's event, it's preferred to pass a prop down. Then, use the watch property on that prop in the child component to create the desired side effect. 
+If you are in a Vue app that doesn't use any event hub, try to avoid adding a new one unless absolutely necessary. For example, if you need a child component to react to its parent's event, it's preferred to pass a prop down. Then, use the watch property on that prop in the child component to create the desired side effect.
 
 If you need cross-component communication (between different Vue apps), then perhaps introducing a hub is the right decision.
 
diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md
index b38696263b406f959b283a798dc00a3b7276ac1c..c32789740c3a09bae7321acb7b2fce41bcd1532e 100644
--- a/doc/development/service_ping/implement.md
+++ b/doc/development/service_ping/implement.md
@@ -27,7 +27,7 @@ To implement a new metric in Service Ping, follow these steps:
 1. [Set up and test Service Ping locally](#set-up-and-test-service-ping-locally)
 
 NOTE:
-When you add or change a Service Metric, you must migrate metrics to [instrumentation classes](metrics_instrumentation.md). 
+When you add or change a Service Metric, you must migrate metrics to [instrumentation classes](metrics_instrumentation.md).
 For information about the progress on migrating Service ping metrics, see this [epic](https://gitlab.com/groups/gitlab-org/-/epics/5547).
 
 ## Instrumentation classes
diff --git a/doc/development/service_ping/index.md b/doc/development/service_ping/index.md
index 0b8bc42276c06ff4dd89bd0b90e731a830b5691b..1f751eea4d8396debfdfb569ba35a03d5af0e0eb 100644
--- a/doc/development/service_ping/index.md
+++ b/doc/development/service_ping/index.md
@@ -21,7 +21,7 @@ and sales teams understand how GitLab is used. The data helps to:
 Service Ping information is not anonymous. It's linked to the instance's hostname, but does
 not contain project names, usernames, or any other specific data.
 
-Sending a Service Ping payload is optional and you can [disable](#disable-service-ping) it on any 
+Sending a Service Ping payload is optional and you can [disable](#disable-service-ping) it on any
 self-managed instance. When Service Ping is enabled, GitLab gathers data from the other instances
 and can show your instance's usage statistics to your users.
 
@@ -41,10 +41,10 @@ We use the following terminology to describe the Service Ping components:
 
 The main purpose of Service Ping is to build a better GitLab. We collect data about how GitLab is used
 to understand feature or stage adoption and usage. This data gives an insight into how GitLab adds
-value and helps our team understand the reasons why people use GitLab, and with this knowledge we're able to 
+value and helps our team understand the reasons why people use GitLab, and with this knowledge we're able to
 make better product decisions.
 
-There are several other benefits to enabling Service Ping: 
+There are several other benefits to enabling Service Ping:
 
 - As a benefit of having Service Ping active, GitLab lets you analyze the users' activities over time of your GitLab installation.
 - As a benefit of having Service Ping active, GitLab provides you with [DevOps Score](../../user/admin_area/analytics/dev_ops_report.md#devops-score), which gives you an overview of your entire instance's adoption of Concurrent DevOps from planning to monitoring.
diff --git a/doc/development/sidekiq_style_guide.md b/doc/development/sidekiq_style_guide.md
index f4fe80ad15ee035a13ddddaf3e98407d9fe74ffe..a643b89b7ff322702e9b5df6af2cbee55e51168f 100644
--- a/doc/development/sidekiq_style_guide.md
+++ b/doc/development/sidekiq_style_guide.md
@@ -354,7 +354,7 @@ This way we are always comparing the latest binary replication pointer,
 making sure that we read from the replica that is fully caught up.
 
 FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to 
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to
 [disable the feature flag](../administration/feature_flags.md) named preserve_latest_wal_locations_for_idempotent_jobs flag.
 
 This feature flag is related to GitLab development and is not intended to be used by GitLab administrators, though.
diff --git a/doc/development/snowplow/implementation.md b/doc/development/snowplow/implementation.md
index fe1de789eae0563a63aec79cddf1e961d5b0da07..3ffacc5af67354b78d97349f0b74eaed6b9f88af 100644
--- a/doc/development/snowplow/implementation.md
+++ b/doc/development/snowplow/implementation.md
@@ -13,12 +13,12 @@ This page describes how to:
 
 ## Snowplow JavaScript frontend tracking
 
-GitLab provides a `Tracking` interface that wraps the [Snowplow JavaScript tracker](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/) 
-to track custom events. 
+GitLab provides a `Tracking` interface that wraps the [Snowplow JavaScript tracker](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/)
+to track custom events.
 
 For the recommended frontend tracking implementation, see [Usage recommendations](#usage-recommendations).
 
-Tracking implementations must have an `action` and a `category`. You can provide additional 
+Tracking implementations must have an `action` and a `category`. You can provide additional
 categories from the [structured event taxonomy](index.md#structured-event-taxonomy) with an `extra` object
 that accepts key-value pairs.
 
@@ -67,8 +67,8 @@ The following example shows `data-track-*` attributes assigned to a button:
 #### Event listeners
 
 Event listeners bind at the document level to handle click events in elements with data attributes.
-This allows them to be handled when the DOM re-renders or changes. Document-level binding reduces 
-the likelihood that click events stop propagating up the DOM tree. 
+This allows them to be handled when the DOM re-renders or changes. Document-level binding reduces
+the likelihood that click events stop propagating up the DOM tree.
 
 If click events stop propagating, you must implement listeners and [Vue component tracking](#implement-vue-component-tracking) or [raw JavaScript tracking](#implement-raw-javascript-tracking).
 
@@ -102,12 +102,12 @@ track_action: "click_button" })
 ### Implement Vue component tracking
 
 For custom event tracking, use a Vue `mixin` in components. Vue `mixin` exposes the `Tracking.event`
-static method and the `track` method. You can specify tracking options in `data` or `computed`. 
-These options override any defaults and allow the values to be dynamic from props or based on state. 
+static method and the `track` method. You can specify tracking options in `data` or `computed`.
+These options override any defaults and allow the values to be dynamic from props or based on state.
 
-Several default options are passed when an event is tracked from the component: 
+Several default options are passed when an event is tracked from the component:
 
-- `category`: If you don't specify, by default `document.body.dataset.page` is used. 
+- `category`: If you don't specify, by default `document.body.dataset.page` is used.
 - `label`
 - `property`
 - `value`
@@ -121,7 +121,7 @@ To implement Vue component tracking:
     const trackingMixin = Tracking.mixin;
     ```
 
-1. Provide categories to track the event from the component. For example, to track all events in a 
+1. Provide categories to track the event from the component. For example, to track all events in a
 component with a label, use the `label` category:
 
     ```javascript
@@ -293,14 +293,14 @@ describe('MyTracking', () => {
 
 ### Form tracking
 
-To enable Snowplow automatic [form tracking](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracking-specific-events/#form-tracking): 
+To enable Snowplow automatic [form tracking](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracking-specific-events/#form-tracking):
 
-1. Call `Tracking.enableFormTracking` when the DOM is ready. 
+1. Call `Tracking.enableFormTracking` when the DOM is ready.
 1. Provide a `config` object that includes at least one of the following elements:
     - `forms` determines the forms to track. Identified by the CSS class name.
     - `fields` determines the fields inside the tracked forms to track. Identified by the field `name`.
 1. Optional. Provide a list of contexts as the second argument. The [`gitlab_standard`](schemas.md#gitlab_standard) schema is excluded from these events.
-    
+
 ```javascript
 Tracking.enableFormTracking({
   forms: { allow: ['sign-in-form', 'password-recovery-form'] },
@@ -339,7 +339,7 @@ Backend tracking provides:
 - User behavior tracking
 - Instrumentation to monitor and visualize performance over time in a section or aspect of code.
 
-To add custom event tracking and instrumentation, call the `GitLab::Tracking.event` class method. 
+To add custom event tracking and instrumentation, call the `GitLab::Tracking.event` class method.
 For example:
 
 ```ruby
@@ -370,7 +370,7 @@ Use the following arguments:
 
 ### Unit testing
 
-To test backend Snowplow events, use the `expect_snowplow_event` helper. For more information, see 
+To test backend Snowplow events, use the `expect_snowplow_event` helper. For more information, see
 [testing best practices](../testing_guide/best_practices.md#test-snowplow-events).
 
 ### Performance
@@ -419,17 +419,17 @@ Snowplow Inspector Chrome Extension is a browser extension for testing frontend
 
 [Snowplow Micro](https://snowplowanalytics.com/blog/2019/07/17/introducing-snowplow-micro/) is a
 Docker-based solution for testing backend and frontend in a local development environment. Snowplow Micro
-records the same events as the full Snowplow pipeline. To query events, use the Snowplow Micro API. 
+records the same events as the full Snowplow pipeline. To query events, use the Snowplow Micro API.
 
-To install and run Snowplow Micro, complete these steps to modify the 
+To install and run Snowplow Micro, complete these steps to modify the
 [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit):
 
 1. Ensure [Docker is installed](https://docs.docker.com/get-docker/) and running.
 
-1. To install Snowplow Micro, clone the settings in 
+1. To install Snowplow Micro, clone the settings in
 [this project](https://gitlab.com/gitlab-org/snowplow-micro-configuration).
 
-1. Navigate to the directory with the cloned project, 
+1. Navigate to the directory with the cloned project,
    and start the appropriate Docker container:
 
    ```shell
diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md
index 757fb53ec2ec387612b5228cc0b066126085b2fd..abd3b978f5d37bb5732ef87472e0d2c3ac5c0dec 100644
--- a/doc/integration/elasticsearch.md
+++ b/doc/integration/elasticsearch.md
@@ -93,7 +93,7 @@ the indexer itself.
 
 This project relies on [International Components for Unicode](https://icu.unicode.org/) (ICU) for text encoding,
 therefore we must ensure the development packages for your platform are
-installed before running `make`. 
+installed before running `make`.
 
 #### Debian / Ubuntu
 
diff --git a/doc/integration/jira/dvcs.md b/doc/integration/jira/dvcs.md
index 8a1664dff79c25a018367dd07b6f3c971ce577ae..e69b7675a590d9ef4c10163075e584888dd671d1 100644
--- a/doc/integration/jira/dvcs.md
+++ b/doc/integration/jira/dvcs.md
@@ -273,7 +273,7 @@ If you get a `Sync Failed` error in Jira when [refreshing repository data](#refr
 ```plaintext
 Failed to execute request [https://gitlab.com/api/v4/projects/:id/merge_requests?page=1&per_page=100 GET https://gitlab.com/api/v4/projects/:id/merge_requests?page=1&per_page=100 returned a response status of 403 Forbidden] errors:
 {"message":"403 Forbidden"}
-``` 
+```
 
 If you find a `{"message":"403 Forbidden"}` error, it is possible that this specific project has some [GitLab features disabled](../../user/project/settings/index.md#sharing-and-permissions).
 In the example above, the merge requests feature is disabled.
diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md
index 5aa75aca8fc6d2f447eefca30875e1b1befdaf72..47ef90cbe55dc1f8f2ad0b479ff9e54f6e468b8b 100644
--- a/doc/security/webhooks.md
+++ b/doc/security/webhooks.md
@@ -27,7 +27,7 @@ sent.
 Webhook requests are made by the GitLab server itself and use a single
 (optional) secret token per hook for authorization (instead of a user or
 repository-specific token). As a result, these requests may have broader access than
-intended, including access to everything running on the server hosting the webhook. This 
+intended, including access to everything running on the server hosting the webhook. This
 may include the GitLab server or API itself (for example, `http://localhost:123`).
 Depending on the called webhook, this may also result in network access
 to other servers within that webhook server's local network (for example,
diff --git a/doc/subscriptions/gitlab_com/index.md b/doc/subscriptions/gitlab_com/index.md
index 404f1a752042516c37bcbb6006749a4583317d4d..e174a144cfcd923e57c0d196b9430b0da2887be4 100644
--- a/doc/subscriptions/gitlab_com/index.md
+++ b/doc/subscriptions/gitlab_com/index.md
@@ -323,7 +323,7 @@ To purchase additional minutes for your personal namespace:
 1. Select **Edit profile**.
 1. On the left sidebar, select **Usage Quotas**.
 1. Select **Buy additional minutes** and GitLab redirects you to the Customers Portal.
-1. Locate the subscription card that's linked to your personal namespace on GitLab SaaS, click **Buy more CI minutes**, and complete the details about the transaction. 
+1. Locate the subscription card that's linked to your personal namespace on GitLab SaaS, click **Buy more CI minutes**, and complete the details about the transaction.
 
 After we process your payment, the extra CI minutes are synced to your group
 namespace.
diff --git a/doc/topics/cron/index.md b/doc/topics/cron/index.md
index 3947a72cac6ace12142aabd48e60d4547b9f8f7c..b58f5e6c5ebc395b44e0e7484f50b536285616c2 100644
--- a/doc/topics/cron/index.md
+++ b/doc/topics/cron/index.md
@@ -66,6 +66,6 @@ More examples of how to write a cron schedule can be found at
 
 GitLab uses [`fugit`](https://github.com/floraison/fugit) to parse cron syntax
 strings on the server and [cron-validator](https://github.com/TheCloudConnectors/cron-validator)
-to validate cron syntax in the browser. GitLab uses 
+to validate cron syntax in the browser. GitLab uses
 [`cRonstrue`](https://github.com/bradymholt/cRonstrue) to convert cron to human-readable strings
 in the browser.
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 7a7b7cfe1a803711955e1c02b043c296f58d12be..aafaabad81f480154e87c518838768597656be61 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -242,7 +242,7 @@ Announced: 2021-11-22
 
 ### Value Stream Analytics filtering calculation change
 
-We are changing how the date filter works in Value Stream Analytics. Instead of filtering by the time that the issue or merge request was created, the date filter will filter by the end event time of the given stage. This will result in completely different figures after this change has rolled out. 
+We are changing how the date filter works in Value Stream Analytics. Instead of filtering by the time that the issue or merge request was created, the date filter will filter by the end event time of the given stage. This will result in completely different figures after this change has rolled out.
 
 If you monitor Value Stream Analytics metrics and rely on the date filter, to avoid losing data, you must save the data prior to this change.
 
diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md
index 35d5d56761dd9e9b639c1e5a670dca88ddffcd97..d25caf1d7b4a65f3c90ad4140d46ef2afb9bf278 100644
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@@ -258,7 +258,7 @@ To [Create a new group](../group/index.md#create-a-group) click **New group**.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/340920) in GitLab 14.4.
 
-You can administer all [topics](../project/working_with_projects.md#explore-topics) in the 
+You can administer all [topics](../project/working_with_projects.md#explore-topics) in the
 GitLab instance from the Admin Area's Topics page.
 
 To access the Topics page:
diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md
index 0cc21e3f390cdb251e2b163f410f9ab793633703..6a157dbb5ae40392bdd30b61e0004f3137496c70 100644
--- a/doc/user/analytics/index.md
+++ b/doc/user/analytics/index.md
@@ -100,29 +100,29 @@ We use the following terms to describe GitLab analytics:
       - All incidents are related to a [production environment](../../ci/environments/index.md#deployment-tier-of-environments).
       - Incidents and deployments have a strictly one-to-one relationship (meaning any incident is related to only one production deployment, and any production deployment is related to no more than one incident).
 
-- **Lead time:** The duration of your value stream, from start to finish. Different to 
-[Lead time for changes](#lead-time-for-changes). Often displayed in combination with "cycle time," 
-which is shorter. GitLab measures lead time from issue creation to issue close. GitLab displays lead 
+- **Lead time:** The duration of your value stream, from start to finish. Different to
+[Lead time for changes](#lead-time-for-changes). Often displayed in combination with "cycle time,"
+which is shorter. GitLab measures lead time from issue creation to issue close. GitLab displays lead
 time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md).
-- **Mean Time to Change (MTTC):** The average duration between idea and delivery. GitLab measures 
+- **Mean Time to Change (MTTC):** The average duration between idea and delivery. GitLab measures
 MTTC from issue creation to the issue's latest related merge request's deployment to production.
-- **Mean Time to Detect (MTTD):** The average duration that a bug goes undetected in production. 
+- **Mean Time to Detect (MTTD):** The average duration that a bug goes undetected in production.
 GitLab measures MTTD from deployment of bug to issue creation.
-- **Mean Time To Merge (MTTM):** The average lifespan of a merge request. GitLab measures MTTM from 
-merge request creation to merge request merge (and closed/un-merged merge requests are excluded). 
+- **Mean Time To Merge (MTTM):** The average lifespan of a merge request. GitLab measures MTTM from
+merge request creation to merge request merge (and closed/un-merged merge requests are excluded).
 For more information, see [Merge Request Analytics](merge_request_analytics.md).
-- **Mean Time to Recover/Repair/Resolution/Resolve/Restore (MTTR):** The average duration that a bug 
+- **Mean Time to Recover/Repair/Resolution/Resolve/Restore (MTTR):** The average duration that a bug
 is not fixed in production. GitLab measures MTTR from deployment of bug to deployment of fix.
-- **Throughput:** The number of issues closed or merge requests merged (not closed) in a period of 
+- **Throughput:** The number of issues closed or merge requests merged (not closed) in a period of
 time. Often measured per sprint. GitLab displays merge request throughput in [Merge Request Analytics](merge_request_analytics.md).
-- **Value Stream:** The entire work process that is followed to deliver value to customers. For example, 
-the [DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/) is a value stream that starts 
+- **Value Stream:** The entire work process that is followed to deliver value to customers. For example,
+the [DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/) is a value stream that starts
 with "plan" and ends with "monitor". GitLab helps you track your value stream using [Value Stream Analytics](value_stream_analytics.md).
-- **Velocity:** The total issue burden completed in some period of time. The burden is usually measured 
-in points or weight, often per sprint. For example, your velocity may be "30 points per sprint". GitLab 
+- **Velocity:** The total issue burden completed in some period of time. The burden is usually measured
+in points or weight, often per sprint. For example, your velocity may be "30 points per sprint". GitLab
 measures velocity as the total points or weight of issues closed in a given period of time.
 
 ## Lead time for changes
 
-"Lead Time for Changes" differs from "Lead Time" because it "focuses on measuring only the time to 
+"Lead Time for Changes" differs from "Lead Time" because it "focuses on measuring only the time to
 deliver a feature once it has been developed", as described in ([Measuring DevOps Performance](https://devops.com/measuring-devops-performance/)).
diff --git a/doc/user/analytics/productivity_analytics.md b/doc/user/analytics/productivity_analytics.md
index da55a0f093cf5f26f4663c8435a2dda42616b4f1..e1ba2f5565e97c6e2ae2b559781c01c2dcf586bf 100644
--- a/doc/user/analytics/productivity_analytics.md
+++ b/doc/user/analytics/productivity_analytics.md
@@ -34,14 +34,14 @@ Metrics and visualizations of **merged** merge requests are available on a proje
 
 ### Time to merge
 
-The **Time to merge** histogram shows the number of merge requests and the number 
+The **Time to merge** histogram shows the number of merge requests and the number
 of days it took to merge after creation. Select a column to filter subsequent charts.
 
 ![Metrics for number of days merge requests per number of days](img/productivity_analytics_time_to_merge_v14_4.png)
 
 ### Trendline
 
-The **Trendline** scatterplot shows all merge requests on a certain date, 
+The **Trendline** scatterplot shows all merge requests on a certain date,
 and the days it took to complete the action and a 30 day rolling median. Select the dropdown to view:
 
 - Time from first commit to first comment.
@@ -55,15 +55,15 @@ and the days it took to complete the action and a 30 day rolling median. Select
 
 ### Commits and merge request size
 
-Under the **Trendline** scatterplot, the left-side histogram shows 
-the time taken (in hours) between commits and comments until the merge 
+Under the **Trendline** scatterplot, the left-side histogram shows
+the time taken (in hours) between commits and comments until the merge
 request is merged. Select the dropdown to view:
 
 - Time from first commit to first comment.
 - Time from first comment until last commit.
 - Time from last commit to merge.
 
-The right-side histogram shows the size or complexity of a merge request. 
+The right-side histogram shows the size or complexity of a merge request.
 Select the dropdown to view:
   
 - Number of commits per merge request.
@@ -74,7 +74,7 @@ Select the dropdown to view:
 
 ### Merge request list
 
-The **List** table shows a list of merge requests with their respective time duration metrics. 
+The **List** table shows a list of merge requests with their respective time duration metrics.
 
 Sort metrics by:
 
@@ -83,7 +83,7 @@ Sort metrics by:
 - Time from last commit to merge.
 
 Filter metrics by:
- 
+
 - Number of commits per merge request.
 - Number of lines of code per commit.
 - Number of files touched.
diff --git a/doc/user/application_security/api_fuzzing/index.md b/doc/user/application_security/api_fuzzing/index.md
index 9ba24d9931f16b20193fbc556b5f0ff576593bf1..d96d28d3c667fe891852d69d1791f6521cb2743f 100644
--- a/doc/user/application_security/api_fuzzing/index.md
+++ b/doc/user/application_security/api_fuzzing/index.md
@@ -14,7 +14,7 @@ miss.
 
 INFO:
 Try fuzz testing in GitLab Ultimate.
-[It's free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-api-fuzzing-docs). 
+[It's free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-api-fuzzing-docs).
 
 We recommend that you use fuzz testing in addition to [GitLab Secure](../index.md)'s
 other security scanners and your own test processes. If you're using [GitLab CI/CD](../../../ci/index.md),
diff --git a/doc/user/application_security/dast/browser_based.md b/doc/user/application_security/dast/browser_based.md
index 7e3d927f31d00913b05f78376e994c060fe46dfd..f63ed2a5079baccc790c3cbec5f1e389f1429894 100644
--- a/doc/user/application_security/dast/browser_based.md
+++ b/doc/user/application_security/dast/browser_based.md
@@ -69,7 +69,7 @@ The browser-based crawler can be configured using CI/CD variables.
 | `DAST_BROWSER_SEARCH_ELEMENT_TIMEOUT`        | [Duration string](https://golang.org/pkg/time/#ParseDuration) | `3s`    | The maximum amount of time to allow the browser to search for new elements or navigations. |
 | `DAST_BROWSER_EXTRACT_ELEMENT_TIMEOUT`       | [Duration string](https://golang.org/pkg/time/#ParseDuration) | `5s`    | The maximum amount of time to allow the browser to extract newly found elements or navigations. |
 | `DAST_BROWSER_ELEMENT_TIMEOUT`               | [Duration string](https://golang.org/pkg/time/#ParseDuration) | `600ms` | The maximum amount of time to wait for an element before determining it is ready for analysis. |
-| `DAST_BROWSER_PAGE_READY_SELECTOR`           | selector | `css:#page-is-ready`                               | Selector that when detected as visible on the page, indicates to the analyzer that the page has finished loading and the scan can continue. Note: When this selector is set, but the element is not found, the scanner waits for the period defined in `DAST_BROWSER_STABILITY_TIMEOUT` before continuing the scan. This can significantly increase scanning time if the element is not present on multiple pages within the site. |        
+| `DAST_BROWSER_PAGE_READY_SELECTOR`           | selector | `css:#page-is-ready`                               | Selector that when detected as visible on the page, indicates to the analyzer that the page has finished loading and the scan can continue. Note: When this selector is set, but the element is not found, the scanner waits for the period defined in `DAST_BROWSER_STABILITY_TIMEOUT` before continuing the scan. This can significantly increase scanning time if the element is not present on multiple pages within the site. |
 
 The [DAST variables](index.md#available-cicd-variables) `SECURE_ANALYZERS_PREFIX`, `DAST_FULL_SCAN_ENABLED`, `DAST_AUTO_UPDATE_ADDONS`, `DAST_EXCLUDE_RULES`, `DAST_REQUEST_HEADERS`, `DAST_HTML_REPORT`, `DAST_MARKDOWN_REPORT`, `DAST_XML_REPORT`,
 `DAST_AUTH_URL`, `DAST_USERNAME`, `DAST_PASSWORD`, `DAST_USERNAME_FIELD`, `DAST_PASSWORD_FIELD`, `DAST_FIRST_SUBMIT_FIELD`, `DAST_SUBMIT_FIELD`, `DAST_EXCLUDE_URLS`, `DAST_AUTH_VERIFICATION_URL`, `DAST_BROWSER_AUTH_VERIFICATION_SELECTOR`, `DAST_BROWSER_AUTH_VERIFICATION_LOGIN_FORM`, `DAST_BROWSER_AUTH_REPORT`,
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index bfe0d8c2b9eed2fc89ebfeb933b28e82a4ccc7be..8f26bc8a46ca09fe8539abc46969ff9dfad4e717 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -18,7 +18,7 @@ tool [OWASP Zed Attack Proxy](https://www.zaproxy.org/) for analysis.
 
 INFO:
 Want to try out security scanning?
-[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-dast-docs). 
+[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-dast-docs).
 
 After DAST creates its report, GitLab evaluates it for discovered
 vulnerabilities between the source and target branches. Relevant
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index d2029be7f3dd5c07ec98c76f0fd98381db314729..20d7b1931a0f4d038600f7be2204a28881b605bc 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -18,7 +18,7 @@ actionable information _before_ changes are merged enables you to be proactive.
 
 INFO:
 Want to try out security scanning?
-[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-application-security-docs). 
+[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-application-security-docs).
 
 GitLab also provides high-level statistics of vulnerabilities across projects and groups:
 
diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md
index 18635599dda7abc47a877532ebc4ba6167f68fc2..122d462ac961c68fffa41b8e631a43812b66a73f 100644
--- a/doc/user/application_security/security_dashboard/index.md
+++ b/doc/user/application_security/security_dashboard/index.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 INFO:
 Want to try out security scanning?
-[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-security-dashboard-docs). 
+[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-security-dashboard-docs).
 
 GitLab provides a comprehensive set of features for viewing and managing vulnerabilities:
 
diff --git a/doc/user/clusters/agent/index.md b/doc/user/clusters/agent/index.md
index 3f639322c8f1797177e481c88d8398ab802526c6..bbd8ebaf54c2fa9f03b5b02b84e711e17d05b3b4 100644
--- a/doc/user/clusters/agent/index.md
+++ b/doc/user/clusters/agent/index.md
@@ -19,7 +19,7 @@ The Agent is installed into the cluster through code, providing you with a fast,
 
 INFO:
 Get Network Security Alerts in GitLab by upgrading to Ultimate.
-[Try a free 30-day trial now](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=p-cluster-agent-docs). 
+[Try a free 30-day trial now](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=p-cluster-agent-docs).
 
 With GitOps, you can manage containerized clusters and applications from a Git repository that:
 
diff --git a/doc/user/clusters/agent/install/index.md b/doc/user/clusters/agent/install/index.md
index fad9d4f08f1a0020365e4c8487a8ae6876d12c49..83031c30e59af39e0014e09dab7fe30e60235135 100644
--- a/doc/user/clusters/agent/install/index.md
+++ b/doc/user/clusters/agent/install/index.md
@@ -353,7 +353,7 @@ Additional management interfaces are planned for the GitLab Kubernetes Agent.
 
 ## Upgrades and version compatibility
 
-The GitLab Kubernetes Agent is comprised of two major components: `agentk` and `kas`. 
+The GitLab Kubernetes Agent is comprised of two major components: `agentk` and `kas`.
 As we provide `kas` installers built into the various GitLab installation methods, the required `kas` version corresponds to the GitLab `major.minor` (X.Y) versions.
 
 At the same time, `agentk` and `kas` can differ by 1 minor version in either direction. For example,
diff --git a/doc/user/compliance/license_compliance/index.md b/doc/user/compliance/license_compliance/index.md
index 7b8c2d5cff8b6cecf12f39f524943a0c2fb0ca8b..f92c2cd9a05a6aa48ace5e33554a534ca1a624b5 100644
--- a/doc/user/compliance/license_compliance/index.md
+++ b/doc/user/compliance/license_compliance/index.md
@@ -16,7 +16,7 @@ is incompatible with yours, then you can deny the use of that license.
 
 INFO:
 Try License Compliance scanning to search project dependencies in GitLab Ultimate.
-[It's free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-compliance-docs). 
+[It's free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-compliance-docs).
 
 You can take advantage of License Compliance by either:
 
@@ -194,8 +194,8 @@ directory of your project.
 
 ### Working with Monorepos
 
-Depending on your language, you may need to specify the path to the individual 
-projects of a monorepo using the `LICENSE_FINDER_CLI_OPTS` variable. Passing in 
+Depending on your language, you may need to specify the path to the individual
+projects of a monorepo using the `LICENSE_FINDER_CLI_OPTS` variable. Passing in
 the project paths can significantly speed up builds over using the `--recursive`
 license_finder option.
 
diff --git a/doc/user/group/devops_adoption/index.md b/doc/user/group/devops_adoption/index.md
index c67fa4abfc5eb8dc77f006fb382cb6c475a442e5..4151745189dcf2068b93984078b0d55588c63305 100644
--- a/doc/user/group/devops_adoption/index.md
+++ b/doc/user/group/devops_adoption/index.md
@@ -22,7 +22,7 @@ You can use Group DevOps Adoption to:
 
 - Identify specific subgroups that are lagging in their adoption of GitLab features, so you can guide them on
 their DevOps journey.
-- Find subgroups that have adopted certain features, and provide guidance to other subgroups on 
+- Find subgroups that have adopted certain features, and provide guidance to other subgroups on
 how to use those features.
 - Verify if you are getting the return on investment that you expected from GitLab.
 
@@ -51,7 +51,7 @@ DevOps Adoption shows feature adoption for development, security, and operations
 
 ## Feature adoption
 
-DevOps Adoption shows feature adoption data for groups and subgroups for the previous calendar month. 
+DevOps Adoption shows feature adoption data for groups and subgroups for the previous calendar month.
 
 A feature shows as **adopted** when a group has used the feature in a project during the time period.
 This includes projects in any subgroups of the group. For example, if an issue was created in a project in a group, the group has adopted issues in that time.
@@ -63,12 +63,12 @@ When GitLab measures DevOps Adoption, some common DevOps information is not incl
 - Dormant projects. It doesn't matter how many projects in the group use a feature. Even if you have many dormant projects, it doesn't lower the adoption.
 - New GitLab features. Adoption is the total number of features adopted, not the percent of features.
 
-## When DevOps Adoption data is gathered 
+## When DevOps Adoption data is gathered
 
-A weekly task processes data for DevOps Adoption. This task is disabled until you access 
-DevOps Adoption for a group for the first time. 
+A weekly task processes data for DevOps Adoption. This task is disabled until you access
+DevOps Adoption for a group for the first time.
 
-The data processing task updates the data on the first day of each month. If the monthly update 
+The data processing task updates the data on the first day of each month. If the monthly update
 fails, the task tries daily until it succeeds.
 
 DevOps Adoption data may take up to a minute to appear while GitLab processes the group's data.
@@ -76,13 +76,13 @@ DevOps Adoption data may take up to a minute to appear while GitLab processes th
 ## View feature adoption over time
 
 The **Adoption over time** chart shows the total number of adopted features from the previous
-twelve months. The chart only shows data from when you enabled DevOps Adoption for the group. 
+twelve months. The chart only shows data from when you enabled DevOps Adoption for the group.
 
 To view feature adoption over time:
 
 1. On the top bar, select **Menu > Groups** and find your group.
 1. On the left sidebar, select **Analytics > DevOps adoption**.
-1. Select the **Overview** tab. 
+1. Select the **Overview** tab.
 
 Tooltips display information about the features tracked for individual months.
 
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 42fc2f532e1dbe956f34bf437116ac8758f646c3..a586ef9ffe8ba0c551363d98123bcd3acd0fc2ff 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -568,7 +568,7 @@ You should consider these security implications before configuring IP address re
   the IP restrictions. But when the running CI/CD job sends Git requests from a
   restricted IP address, the IP restriction prevents code from being cloned.
 - **User dashboard activity**: Users may still see some events from the IP restricted groups and projects
-  on their dashboard. Activity may include push, merge, issue, or comment events. 
+  on their dashboard. Activity may include push, merge, issue, or comment events.
 
 To restrict group access by IP address:
 
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 6b3e72230a09be0b3356014334d037a3278396b0..e2a20c1c42758e1ec5371c79774868c048aeecff 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -126,7 +126,7 @@ SSO has the following effects when enabled:
 - For groups, users can't share a project in the group outside the top-level group,
   even if the project is forked.
 - For Git activity over SSH and HTTPS, users must have at least one active session signed-in through SSO before they can push to or
-  pull from a GitLab repository. 
+  pull from a GitLab repository.
 - Credentials that are not tied to regular users (for example, access tokens and deploy keys) do not have the SSO check enforced.
 - Users must be signed-in through SSO before they can pull images using the [Dependency Proxy](../../packages/dependency_proxy/index.md).
 <!-- Add bullet for API activity when https://gitlab.com/gitlab-org/gitlab/-/issues/9152 is complete -->
@@ -369,7 +369,7 @@ To link the SAML groups from the `saml:AttributeStatement` example above:
 If a user is a member of multiple SAML groups mapped to the same GitLab group,
 the user gets the highest access level from the groups. For example, if one group
 is linked as `Guest` and another `Maintainer`, a user in both groups gets `Maintainer`
-access. 
+access.
 
 Users granted:
 
@@ -487,7 +487,7 @@ Specific attention should be paid to:
 
 #### Generate a SAML Response
 
-SAML Responses can be used to preview the attribute names and values sent in the assertions list while attempting to sign in using an IdP. 
+SAML Responses can be used to preview the attribute names and values sent in the assertions list while attempting to sign in using an IdP.
 
 To generate a SAML Response:
 
diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md
index a0a13c71d95acea29865b105396a499adcab473e..b91e258b04aac459395ef2fd82923a1c56f41e6e 100644
--- a/doc/user/group/value_stream_analytics/index.md
+++ b/doc/user/group/value_stream_analytics/index.md
@@ -86,8 +86,8 @@ the date filter behavior to filter the end event time of the currently selected
 The change makes it possible to get a much better picture about the completed items within the
 stage and helps uncover long-running items.
 
-For example, an issue was created a year ago and the current stage was finished in the current month. 
-If you were to look at the metrics for the last three months, this issue would not be included in the calculation of 
+For example, an issue was created a year ago and the current stage was finished in the current month.
+If you were to look at the metrics for the last three months, this issue would not be included in the calculation of
 the stage metrics. With the new date filter, this item would be included.
 
 DISCLAIMER:
@@ -100,7 +100,7 @@ sole discretion of GitLab Inc.
 
 ## How metrics are measured
 
-> DORA API-based deployment metrics for group-level Value Stream Analytics were 
+> DORA API-based deployment metrics for group-level Value Stream Analytics were
 > [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/337256) from GitLab Ultimate to GitLab Premium in 14.3.
 
 The "Time" metrics near the top of the page are measured as follows:
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index a2d9ac21a18761c81376629306ca5ef56125b6e2..90cb6502bbd41cdb848d24572275ad0bf8056868 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -260,7 +260,7 @@ To change your commit email:
 1. In the **Commit email** dropdown list, select an email address.
 1. Select **Update profile settings**.
 
-## Change your primary email 
+## Change your primary email
 
 Your primary email:
 
diff --git a/doc/user/project/repository/gpg_signed_commits/index.md b/doc/user/project/repository/gpg_signed_commits/index.md
index 94fe6ffac567ae21181053d4c56782fdd3ea1211..27767f8d32558bb61639b4a2ccdd0d4e6e5d86c1 100644
--- a/doc/user/project/repository/gpg_signed_commits/index.md
+++ b/doc/user/project/repository/gpg_signed_commits/index.md
@@ -40,7 +40,7 @@ For a commit to be verified by GitLab:
   account.
 - One of the emails in the GPG key must match a **verified** email address
   used by the committer in GitLab. This address will be part of the public key.
-  If you want to keep this address private, use the automatically generated 
+  If you want to keep this address private, use the automatically generated
   [private commit email address](../../../profile/index.md#use-an-automatically-generated-private-commit-email)
   GitLab provides in your profile.
 - The committer's email address must match the verified email address from the