Run whitespace cleanup

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.

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:
 

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:

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,

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:
 

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.
 

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

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.

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.

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).

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

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.
 

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

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.

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.

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

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
 

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.

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,

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.

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.

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.
 

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:

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/)).

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.

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),

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`,

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

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:
 

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:
 

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:
 

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,

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.
 

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.
 

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:
 

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:
 

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:

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:
 

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