Add vale rule to warn about EOL whitespace

The TW team has to clean up stray whitespace every month, so we should have a vale rule to gently warn people when they are introducing EOL whitespace

Add vale rule to warn about EOL whitespace
The TW team has to clean up stray whitespace every month, so we should have a vale rule to gently warn people when they are introducing EOL whitespace
9faad3ad · Marcel Amirault · b479aaca · 9faad3ad · 9faad3ad · 9faad3ad
--- a/doc/.vale/gitlab/EOLWhitespace.yml
+++ b/doc/.vale/gitlab/EOLWhitespace.yml
+---
+# Error: gitlab.EOLWhitespace
+#
+# Checks that there is no useless whitespace at the end of lines.
+#
+# For a list of all options, see https://errata-ai.gitbook.io/vale/getting-started/styles
+extends: existence
+message: 'Lines should not end with whitespace characters.'
+link: https://docs.gitlab.com/ee/development/documentation/versions.html
+level: warning
+scope: raw
+raw:
+  - ' +\n'
--- a/doc/administration/audit_event_streaming.md
+++ b/doc/administration/audit_event_streaming.md
@@ -132,7 +132,7 @@ Delete an event streaming destination by specifying an ID. Get the required ID b
 streaming destinations.

 ```graphql
-mutation { 
+mutation {
  externalAuditEventDestinationDestroy(input: { id: destination }) {
    errors
  }

--- a/doc/administration/auth/ldap/ldap-troubleshooting.md
+++ b/doc/administration/auth/ldap/ldap-troubleshooting.md
@@ -88,7 +88,7 @@ options = {

    # :filter is optional
    # This filter includes OID 1.2.840.113556.1.4.1941
-    # It will search for all direct and nested members of the group gitlab_grp in the LDAP directory  
+    # It will search for all direct and nested members of the group gitlab_grp in the LDAP directory
    filter: Net::LDAP::Filter.construct("(memberOf:1.2.840.113556.1.4.1941:=CN=gitlab_grp,DC=example,DC=com)"),

    # :attributes is optional

--- a/doc/administration/geo/replication/docker_registry.md
+++ b/doc/administration/geo/replication/docker_registry.md
@@ -114,10 +114,10 @@ For each application and Sidekiq node on the **secondary** site:

   ```ruby
   gitlab_rails['geo_registry_replication_enabled'] = true
-   
+
   # Primary registry's hostname and port, it will be used by
   # the secondary node to directly communicate to primary registry
-   gitlab_rails['geo_registry_replication_primary_api_url'] = 'https://primary.example.com:5050/' 
+   gitlab_rails['geo_registry_replication_primary_api_url'] = 'https://primary.example.com:5050/'
   ```

 1. Reconfigure the node for the change to take effect:

--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -1129,7 +1129,7 @@ Geo::TrackingBase::SecondaryNotConfigured: Geo secondary database is not configu

 On a Geo primary site this error can be ignored.

-This happens because GitLab is attempting to display registries from the [Geo tracking database](../../../administration/geo/#geo-tracking-database) which doesn't exist on the primary site (only the original projects exist on the primary; no replicated projects are present, therefore no tracking database exists). 
+This happens because GitLab is attempting to display registries from the [Geo tracking database](../../../administration/geo/#geo-tracking-database) which doesn't exist on the primary site (only the original projects exist on the primary; no replicated projects are present, therefore no tracking database exists).

 ## Fixing client errors

@@ -1148,7 +1148,7 @@ The partial failover to a secondary Geo *site* may be the result of a temporary/
 1. SSH into every Sidekiq, PostgresSQL, Gitaly, and Rails node in the **secondary** site and run one of the following commands:

   - To promote the secondary node to primary:
-     
+
     ```shell
     sudo gitlab-ctl geo promote
     ```
@@ -1158,8 +1158,8 @@ The partial failover to a secondary Geo *site* may be the result of a temporary/
     ```shell
     sudo gitlab-ctl geo promote --force
     ```
-     
-1. Verify you can connect to the newly-promoted **primary** site using the URL used previously for the **secondary** site.  
+
+1. Verify you can connect to the newly-promoted **primary** site using the URL used previously for the **secondary** site.
 1. If **successful**, the **secondary** site is now promoted to the **primary** site.

 If the above steps are **not successful**, proceed through the next steps:

--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -475,7 +475,7 @@ Updates to example must be made at:

   # Some metrics run queries against the database. Enabling separate database metrics allows
   # these metrics to be collected when the metrics are
-   # scraped on a separate /db_metrics endpoint. 
+   # scraped on a separate /db_metrics endpoint.
   praefect['separate_database_metrics'] = true
   ```


--- a/doc/administration/gitaly/recovery.md
+++ b/doc/administration/gitaly/recovery.md
@@ -359,7 +359,7 @@ Add the `-older-than` option to avoid showing repositories that are the process
 Praefect database. Replace `<duration>` with a time duration (for example, `5s`, `10m`, or `1h`). Defaults to `6h`.

 ```shell
-sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml list-untracked-repositories -older-than <duration> 
+sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml list-untracked-repositories -older-than <duration>
 ```

 Only repositories with a creation time before the specified duration are considered.

--- a/doc/administration/monitoring/prometheus/index.md
+++ b/doc/administration/monitoring/prometheus/index.md
@@ -137,8 +137,8 @@ The steps below are the minimum necessary to configure a Monitoring node running

   # Enable service discovery for Prometheus
   consul['enable'] = true
-   consul['monitoring_service_discovery'] =  true
-   consul['configuration'] = { 
+   consul['monitoring_service_discovery'] = true
+   consul['configuration'] = {
      retry_join: %w(10.0.0.1 10.0.0.2 10.0.0.3), # The addresses can be IPs or FQDNs
   }


--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -765,7 +765,7 @@ Prerequisites:

 1. [Install](https://rclone.org/downloads/) Rclone.
 1. Configure Rclone by running the following:
-   
+
   ```shell
   rclone config
   ```
@@ -778,7 +778,7 @@ Prerequisites:
   rclone ls old:uploads | head
   ```

-   This should print a partial list of the objects currently stored in your `uploads` bucket. If you get an error, or if 
+   This should print a partial list of the objects currently stored in your `uploads` bucket. If you get an error, or if
   the list is empty, go back and update your Rclone configuration using `rclone config`.

 1. Perform an initial copy. You do not need to take your GitLab server offline for this step.
@@ -788,7 +788,7 @@ Prerequisites:
   ```

 1. After the first sync completes, use the web UI or command-line interface of your new object storage provider to
-   verify that there are objects in the new bucket. If there are none, or if you encounter an error while running `rclone 
+   verify that there are objects in the new bucket. If there are none, or if you encounter an error while running `rclone
   sync`, check your Rclone configuration and try again.

 After you have done at least one successful Rclone copy from the old location to the new location, schedule maintenance and take your GitLab server offline. During your maintenance window you must do two things:

--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -1729,7 +1729,7 @@ In this case, follow these steps:
   ```ruby
   gitlab_rails['registry_enabled'] = true
   ```
-  
+
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
   for the changes to take effect.
 1. Try the removal again.

--- a/doc/administration/postgresql/replication_and_failover.md
+++ b/doc/administration/postgresql/replication_and_failover.md
@@ -42,7 +42,7 @@ collections "**Consul** x3" as consul #e76a9b

 card "Database" as database {
  collections "**PGBouncer x3**\n//Consul//" as pgbouncer #4EA7FF
- 
+
  card "**PostgreSQL** //Primary//\n//Patroni//\n//PgBouncer//\n//Consul//" as postgres_primary #4EA7FF
  collections "**PostgreSQL** //Secondary// **x2**\n//Patroni//\n//PgBouncer//\n//Consul//" as postgres_secondary #4EA7FF


--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -86,7 +86,7 @@ card "Database" as database {
 card "redis" as redis {
  collections "**Redis Persistent** x3" as redis_persistent #FF6347
  collections "**Redis Cache** x3" as redis_cache #FF6347
-  
+
  redis_cache -[hidden]-> redis_persistent
 }

@@ -2381,7 +2381,7 @@ card "Database" as database {
 card "redis" as redis {
  collections "**Redis Persistent** x3" as redis_persistent #FF6347
  collections "**Redis Cache** x3" as redis_cache #FF6347
-  
+
  redis_cache -[hidden]-> redis_persistent
 }


--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -215,7 +215,7 @@ table.test-coverage th {

 ## Cost to run

-The following table details the cost to run the different reference architectures across GCP, AWS, and Azure. Bare-metal costs are not included here as it varies widely depending on each customer configuration. 
+The following table details the cost to run the different reference architectures across GCP, AWS, and Azure. Bare-metal costs are not included here as it varies widely depending on each customer configuration.

 <table class="test-coverage">
  <col>

--- a/doc/administration/sidekiq.md
+++ b/doc/administration/sidekiq.md
@@ -233,7 +233,7 @@ To enable LDAP with the synchronization worker for Sidekiq:
   gitlab_rails['ldap_servers'] = {
   'main' => {
   'label' => 'LDAP',
-   'host' =>  'ldap.mydomain.com',
+   'host' => 'ldap.mydomain.com',
   'port' => 389,
   'uid' => 'sAMAccountName',
   'encryption' => 'simple_tls',
@@ -269,7 +269,7 @@ To enable LDAP with the synchronization worker for Sidekiq:
   'external_groups' => [],
   'sync_ssh_keys' => false
   }
-   } 
+   }
   gitlab_rails['ldap_sync_worker_cron'] = "0 */12 * * *"
   ```


--- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
+++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
@@ -760,7 +760,7 @@ parent.members_with_descendants.count
 # This section lists all the groups which are pending deletion
 #
 Group.all.each do |g|
- if g.marked_for_deletion? 
+ if g.marked_for_deletion?
    puts "Group ID: #{g.id}"
    puts "Group name: #{g.name}"
    puts "Group path: #{g.full_path}"

--- a/doc/api/cluster_agents.md
+++ b/doc/api/cluster_agents.md
@@ -380,7 +380,7 @@ Supported attributes:
 | `id`          | integer or string | yes      | ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) maintained by the authenticated user. |
 | `agent_id`    | integer           | yes      | ID of the agent.                                                                                                 |
 | `name`        | string            | yes      | Name for the token.                                                                                              |
-| `description` | string            | no       | Description for the token.                                                                                       |       
+| `description` | string            | no       | Description for the token.                                                                                       |

 Response:


--- a/doc/api/graphql/index.md
+++ b/doc/api/graphql/index.md
@@ -247,11 +247,11 @@ GraphQL mutations can be detected as spam. If a mutation is detected as spam and
 - Use the `captchaSiteKey` to obtain a CAPTCHA response value using the appropriate CAPTCHA API.
  Only [Google reCAPTCHA v2](https://developers.google.com/recaptcha/docs/display) is supported.
 - Resubmit the request with the `X-GitLab-Captcha-Response` and `X-GitLab-Spam-Log-Id` headers set.
-  
+
 NOTE:
 The GitLab GraphiQL implementation doesn't permit passing of headers, so we must write
 this as a cURL query. `--data-binary` is used to properly handle escaped double quotes
-in the JSON-embedded query.  
+in the JSON-embedded query.

 ```shell
 export CAPTCHA_RESPONSE="<CAPTCHA response obtained from CAPTCHA service>"

--- a/doc/api/index.md
+++ b/doc/api/index.md
@@ -90,7 +90,7 @@ end of the API URL.

 NOTE:
 In the example above, replace `gitlab.example.com` with `gitlab.com` to query GitLab.com (GitLab SaaS).
-Access can be denied due to authentication. For more information, see [Authentication](#authentication).  
+Access can be denied due to authentication. For more information, see [Authentication](#authentication).

 ### API request to expose HTTP response headers


--- a/doc/api/lint.md
+++ b/doc/api/lint.md
@@ -126,7 +126,7 @@ Example response:
      "stage":"test",
      "before_script":[],
      "script":["echo 1"],
-      "after_script":[], 
+      "after_script":[],
      "tag_list":[],
      "environment":null,
      "when":"on_success",

--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@@ -646,7 +646,7 @@ To delete a stopped environment in the GitLab UI:

 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208655) in GitLab 13.2.

-You can define a job that accesses an environment for various purposes, such as verification or preparation. This 
+You can define a job that accesses an environment for various purposes, such as verification or preparation. This
 effectively bypasses deployment creation, so that you can adjust your CD workflow more accurately.

 To do so, add either `action: prepare`, `action: verify`, or `action: access` to the `environment` section of your job: