Merge branch 'docs-whitespace-fixes-3' into 'master'

Clean up end of line whitespace

See merge request gitlab-org/gitlab!57083

doc/administration/pages/index.md

@@ -753,7 +753,7 @@ The default value for Omnibus installations is `nil`.
 If left unchanged, GitLab Pages tries to use any available source (either `gitlab` or `disk`). The
 preferred source is `gitlab`, which uses [API-based configuration](#gitlab-api-based-configuration).
 
-On large GitLab instances, using the API-based configuration will significantly improve the pages daemon startup time, as there is no need to load all custom domains configuration into memory. 
+On large GitLab instances, using the API-based configuration will significantly improve the pages daemon startup time, as there is no need to load all custom domains configuration into memory.
 
 For more details see this [blog post](https://about.gitlab.com/blog/2020/08/03/how-gitlab-pages-uses-the-gitlab-api-to-serve-content/).
 
@@ -816,7 +816,7 @@ or persistent errors, or the Pages Daemon serving old content.
 NOTE:
 Expiry, interval and timeout flags use [Golang's duration formatting](https://golang.org/pkg/time/#ParseDuration).
 A duration string is a possibly signed sequence of decimal numbers,
-each with optional fraction and a unit suffix, such as "300ms", "1.5h" or "2h45m". 
+each with optional fraction and a unit suffix, such as "300ms", "1.5h" or "2h45m".
 Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
 
 Examples:

doc/development/fe_guide/graphql.md

@@ -808,7 +808,7 @@ apollo: {
 },
 ```
 
-Then, becasue Etags depend on the request being a `GET` instead of GraphQL's usual `POST`, but our default link library does not support `GET` we need to let our defaut Apollo client know to use a different library. 
+Then, becasue Etags depend on the request being a `GET` instead of GraphQL's usual `POST`, but our default link library does not support `GET` we need to let our defaut Apollo client know to use a different library.
 
 ```javascript
 /* componentMountIndex.js */
@@ -825,7 +825,7 @@ const apolloProvider = new VueApollo({
 
 Keep in mind, this means your app will not batch queries.
 
-Once subscriptions are mature, this process can be replaced by using them and we can remove the separate link library and return to batching queries. 
+Once subscriptions are mature, this process can be replaced by using them and we can remove the separate link library and return to batching queries.
 
 ### Testing
 

doc/development/usage_ping/index.md

@@ -930,7 +930,7 @@ WARNING:
 This feature is intended solely for internal GitLab use.
 
 To add data for aggregated metrics into Usage Ping payload you should add corresponding definition at [`lib/gitlab/usage_data_counters/aggregated_metrics/*.yaml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/aggregated_metrics/) for metrics available at Community Edition and at [`ee/lib/gitlab/usage_data_counters/aggregated_metrics/*.yaml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/usage_data_counters/aggregated_metrics/) for Enterprise Edition ones.
- 
+
 Each aggregate definition includes following parts:
 
 - `name`: Unique name under which the aggregate metric is added to the Usage Ping payload.
@@ -999,7 +999,7 @@ Aggregated metrics collected in `7d` and `28d` time frames are added into Usage
 }
 ```
 
-Aggregated metrics for `all` time frame are present in the `count` top level key, with the `aggregate_` prefix added to their name. 
+Aggregated metrics for `all` time frame are present in the `count` top level key, with the `aggregate_` prefix added to their name.
 
 For example:
 
@@ -1007,7 +1007,7 @@ For example:
 
 Becomes:
 
-`counts.aggregate_example_metrics_intersection` 
+`counts.aggregate_example_metrics_intersection`
 
 ```ruby
 {

doc/integration/elasticsearch.md

@@ -91,12 +91,12 @@ Since Elasticsearch can read and use indices created in the previous major versi
 
 The only thing worth noting is that if you have created your current index before GitLab 13.0, you might want to reindex from scratch (which will implicitly create an alias) in order to use some features, for example [Zero downtime reindexing](#zero-downtime-reindexing). Once you do that, you'll be able to perform zero-downtime reindexing and will benefit from any future features that make use of the alias.
 
-If you are unsure when your current index was created, 
-you can check whether it was created after GitLab 13.0 by using the 
-[Elasticsearch cat aliases API](https://www.elastic.co/guide/en/elasticsearch/reference/7.11/cat-alias.html). 
-If the list of aliases returned contains an entry for `gitlab-production` that points to an index 
-named `gitlab-production-<numerical timestamp>`, your index was created after GitLab 13.0. 
-If the `gitlab-production` alias is missing, you'll need to reindex from scratch to use 
+If you are unsure when your current index was created,
+you can check whether it was created after GitLab 13.0 by using the
+[Elasticsearch cat aliases API](https://www.elastic.co/guide/en/elasticsearch/reference/7.11/cat-alias.html).
+If the list of aliases returned contains an entry for `gitlab-production` that points to an index
+named `gitlab-production-<numerical timestamp>`, your index was created after GitLab 13.0.
+If the `gitlab-production` alias is missing, you'll need to reindex from scratch to use
 features such as Zero-downtime reindexing.
 
 ## Elasticsearch repository indexer

doc/integration/vault.md

@@ -77,7 +77,7 @@ The following assumes you already have Vault installed and running.
    This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we show how you can access this role through the Vault CLI.
 
    WARNING:
-   If you're using a public GitLab instance (GitLab.com or any other instance publicly 
+   If you're using a public GitLab instance (GitLab.com or any other instance publicly
    accessible), it's paramount to specify the `bound_claims` to allow access only to
    members of your group/project. Otherwise, anyone with a public account can access
    your Vault instance.

doc/user/admin_area/credentials_inventory.md

@@ -11,8 +11,8 @@ type: howto
 
 GitLab administrators are responsible for the overall security of their instance. To assist, GitLab provides a Credentials inventory to keep track of all the credentials that can be used to access their self-managed instance.
 
-Using Credentials inventory, you can see all the personal access tokens (PAT), SSH keys, and GPG keys 
-that exist in your GitLab instance. In addition, you can [revoke](#revoke-a-users-personal-access-token) 
+Using Credentials inventory, you can see all the personal access tokens (PAT), SSH keys, and GPG keys
+that exist in your GitLab instance. In addition, you can [revoke](#revoke-a-users-personal-access-token)
 and [delete](#delete-a-users-ssh-key) and see:
 
 - Who they belong to.
@@ -65,7 +65,7 @@ The instance then notifies the user.
 WARNING:
 This feature might not be available to you. Check the **version history** note above for details.
 
-You can view all existing GPG in your GitLab instance by navigating to the 
+You can view all existing GPG in your GitLab instance by navigating to the
 credentials inventory GPG Keys tab, as well as the following properties:
 
 - Who the GPG key belongs to.

doc/user/application_security/index.md

@@ -311,7 +311,7 @@ request created to automatically solve the issue.
 If this action is available:
 
 1. Select the **Resolve with merge request** dropdown, then select **Resolve with merge request**.
-   
+
    ![Create merge request from vulnerability](img/create_mr_from_vulnerability_v13_4.png)
 
 A merge request is created. It that applies the solution to the source branch.