Merge branch 'kpaizee-fix-whitespace' into 'master'

Remove EOL whitespace in doc files

See merge request gitlab-org/gitlab!83584

doc/administration/audit_event_streaming.md

@@ -344,7 +344,7 @@ Content-Type: application/x-www-form-urlencoded
 X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
 ```
 
-### Example request body 
+### Example request body
 
 ```json
 {

doc/administration/geo/replication/version_specific_updates.md

@@ -12,7 +12,7 @@ for updating Geo sites.
 
 ## Updating to 14.9
 
-**DO NOT** update to GitLab 14.9.0. 
+**DO NOT** update to GitLab 14.9.0.
 
 We've discovered an issue with Geo's CI verification feature that may [cause job traces to be lost](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6664). This issue will be fixed in the next patch release.
 

doc/administration/gitaly/praefect.md

@@ -1197,7 +1197,7 @@ You can configure:
   ```
 
 If `default_replication_factor` is unset, the repositories are always replicated on every node defined in `virtual_storages`. If a new
-node is introduced to the virtual storage, both new and existing repositories are replicated to the node automatically. 
+node is introduced to the virtual storage, both new and existing repositories are replicated to the node automatically.
 
 ## Automatic failover and primary election strategies
 

doc/administration/gitaly/troubleshooting.md

@@ -614,7 +614,7 @@ Possible solutions:
 ## Profiling Gitaly
 
 Gitaly exposes several of Golang's built-in performance profiling tools on the Prometheus listen port. For example, if Prometheus is listening
-on port `9236` of the GitLab server: 
+on port `9236` of the GitLab server:
 
 - Get a list of running `goroutines` and their backtraces:
 

doc/administration/job_artifacts.md

@@ -310,8 +310,8 @@ To migrate back to local storage:
 > [In GitLab 14.6](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/76504), we improved the performance of removing expired artifacts, introduced [with a flag](feature_flags.md) named `ci_destroy_all_expired_service`. Disabled by default.
 
 FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to 
-[enable the feature flag](feature_flags.md) named `ci_destroy_all_expired_service`. The feature is not ready for 
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to
+[enable the feature flag](feature_flags.md) named `ci_destroy_all_expired_service`. The feature is not ready for
 production use.
 On GitLab.com, this feature is not available.
 
@@ -641,4 +641,4 @@ WARNING: Uploading artifacts as "archive" to coordinator... POST https://gitlab.
 FATAL: invalid argument
 ```
 
-If a job artifact fails to upload with the above error when using consolidated object storage, make sure you are [using separate buckets](object_storage.md#use-separate-buckets) for each data type. 
+If a job artifact fails to upload with the above error when using consolidated object storage, make sure you are [using separate buckets](object_storage.md#use-separate-buckets) for each data type.

doc/administration/repository_checks.md

@@ -34,7 +34,7 @@ When enabled, GitLab periodically runs a repository check on all project reposit
 repositories to detect possible data corruption. A project is checked no more than once per month.
 Administrators can configure the frequency of repository checks. To edit the frequency:
 
-- For Omnibus GitLab installations, edit `gitlab_rails['repository_check_worker_cron']` in 
+- For Omnibus GitLab installations, edit `gitlab_rails['repository_check_worker_cron']` in
   `/etc/gitlab/gitlab.rb`.
 - For source-based installations, edit `[gitlab.cron_jobs.repository_check_worker]` in
   `/home/git/gitlab/config/gitlab.yml`.

doc/ci/secrets/index.md

@@ -92,8 +92,8 @@ To configure your Vault server:
      specified when the authentication method was configured.
    - `VAULT_AUTH_PATH` - Optional. The path where the authentication method is mounted, default is `jwt`.
    - `VAULT_NAMESPACE` - Optional. The [Vault Enterprise namespace](https://www.vaultproject.io/docs/enterprise/namespaces) to use for reading secrets and authentication.
-     If no namespace is specified, Vault uses the `root` ("`/`") namespace. 
-     The setting is ignored by Vault Open Source. 
+     If no namespace is specified, Vault uses the `root` ("`/`") namespace.
+     The setting is ignored by Vault Open Source.
 
    NOTE:
    Support for providing these values in the user interface [is tracked in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/218677).

doc/development/contributing/verify/index.md

@@ -55,7 +55,7 @@ and they serve us and our users well. Some examples of these principles are that
 - Feedback needs to be available when a user needs it and data can not disappear unexpectedly when engineers need it.
 - It all doesn’t matter if the platform is not secure and we
 are leaking credentials or secrets.
-- When a user provides a set of preconditions in a form of CI/CD configuration, the result should be deterministic each time a pipeline runs, because otherwise the platform might not be trustworthy. 
+- When a user provides a set of preconditions in a form of CI/CD configuration, the result should be deterministic each time a pipeline runs, because otherwise the platform might not be trustworthy.
 - If it is fast, simple to use and has a great UX it will serve our users well.
 
 ## Building things in Verify

doc/development/documentation/styleguide/index.md

@@ -686,7 +686,7 @@ For the heading text, **do not**:
 - Use words that might change in the future. Changing
   a heading changes its anchor URL, which affects other linked pages.
 - Repeat text from earlier headings. For example, instead of `Troubleshooting merge requests`,
-  use `Troubleshooting`. 
+  use `Troubleshooting`.
 - Use links.
 
 ### Anchor links

doc/development/experiment_guide/index.md

@@ -64,8 +64,8 @@ We recommend the following workflow:
 1. **If the experiment is a success**, designers add the new icon or illustration to the Pajamas UI kit as part of the cleanup process.
    Engineers can then add it to the [SVG library](https://gitlab-org.gitlab.io/gitlab-svgs/) and modify the implementation based on the
    [Frontend Development Guidelines](../fe_guide/icons.md#usage-in-hamlrails-2).
-   
-## Turn off all experiments 
+
+## Turn off all experiments
 
 When there is a case on GitLab.com (SaaS) that necessitates turning off all experiments, we have this control.
 

doc/development/integrations/jira_connect.md

@@ -79,7 +79,7 @@ If you use Gitpod and you get an error about Jira not being able to access the d
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81126) in GitLab 14.9 [with a flag](../../administration/feature_flags.md) named `jira_connect_oauth`. Disabled by default.
 
-GitLab for Jira users can authenticate with GitLab using GitLab OAuth. 
+GitLab for Jira users can authenticate with GitLab using GitLab OAuth.
 
 WARNING:
 This feature is not ready for production use. The feature flag should only be enabled in development.

doc/development/integrations/secure.md

@@ -336,7 +336,7 @@ GitLab has the following retention policies for vulnerabilities on non-default b
 
 To view vulnerabilities, either:
 
-- Re-run the pipeline. 
+- Re-run the pipeline.
 - Download the related CI job artifacts if they are available.
 
 NOTE:

doc/development/merge_request_concepts/index.md

@@ -49,7 +49,7 @@ When all of the required merge checks are satisfied a merge request becomes merg
 
 ### Approvals
 
-Approval rules specify users that are required to or can optionally approve a merge request based on some kind of organizational policy. When approvals are required, they effectively become a required merge check. The key differentiator between merge checks and approval rules is that users **do** interact with approval rules, by deciding to approve the merge request. 
+Approval rules specify users that are required to or can optionally approve a merge request based on some kind of organizational policy. When approvals are required, they effectively become a required merge check. The key differentiator between merge checks and approval rules is that users **do** interact with approval rules, by deciding to approve the merge request.
 
 Additionally, approval settings provide configuration options to define how those approval rules are applied in a merge request. They can set limitations, add requirements, or modify approvals.
 

doc/development/product_qualified_lead_guide/index.md

@@ -127,7 +127,7 @@ The flow of a PQL lead is as follows:
 1. Marketo does scoring and sends the form to Salesforce.
 1. Our Sales team uses Salesforce to connect to the leads.
 
-### Trial lead flow 
+### Trial lead flow
 
 #### Trial lead flow on GitLab.com
 
@@ -166,7 +166,7 @@ sequenceDiagram
     HostedPlans|CreateTrialService->create_trial_history#: Creates a record in trial_histories table
 ```
 
-### Hand raise lead flow 
+### Hand raise lead flow
 
 #### Hand raise flow on GitLab.com
 
@@ -196,4 +196,4 @@ sequenceDiagram
     Platypus->>Workato: [lead]
     Workato->>Marketo: [lead]
     Marketo->>Salesforce(SFDC): [lead]
-```      
+```

doc/development/secure_coding_guidelines.md

@@ -1165,7 +1165,7 @@ func printZipContents(src string) error {
 ## Time of check to time of use bugs
 
 Time of check to time of use, or TOCTOU, is a class of error which occur when the state of something changes unexpectedly partway during a process.
-More specifically, it's when the property you checked and validated has changed when you finally get around to using that property. 
+More specifically, it's when the property you checked and validated has changed when you finally get around to using that property.
 
 These types of bugs are often seen in environments which allow multi-threading and concurrency, like filesystems and distributed web applications; these are a type of race condition. TOCTOU also occurs when state is checked and stored, then after a period of time that state is relied on without re-checking its accuracy and/or validity.
 
@@ -1179,7 +1179,7 @@ GitLab-specific example can be found in [this issue](https://gitlab.com/gitlab-o
 
 **Example 3:** you need to fetch a remote file, and perform a `HEAD` request to get and validate the content length and content type. When you subsequently make a `GET` request, though, the file delivered is a different size or different file type. (This is stretching the definition of TOCTOU, but things _have_ changed between time of check and time of use).
 
-**Example 4:** you allow users to upvote a comment if they haven't already. The server is multi-threaded, and you aren't using transactions or an applicable database index. By repeatedly clicking upvote in quick succession a malicious user is able to add multiple upvotes: the requests arrive at the same time, the checks run in parallel and confirm that no upvote exists yet, and so each upvote is written to the database. 
+**Example 4:** you allow users to upvote a comment if they haven't already. The server is multi-threaded, and you aren't using transactions or an applicable database index. By repeatedly clicking upvote in quick succession a malicious user is able to add multiple upvotes: the requests arrive at the same time, the checks run in parallel and confirm that no upvote exists yet, and so each upvote is written to the database.
 
 Here's some pseudocode showing an example of a potential TOCTOU bug:
 

doc/development/service_ping/index.md

@@ -598,7 +598,7 @@ To upload payload manually:
 1. Select **Choose file** and choose the file from p5.
 1. Select **Upload**.
 
-The uploaded file is encrypted and sent using secure [HTTPS protocol](https://en.wikipedia.org/wiki/HTTPS). HTTPS creates a secure 
+The uploaded file is encrypted and sent using secure [HTTPS protocol](https://en.wikipedia.org/wiki/HTTPS). HTTPS creates a secure
 communication channel between web browser and the server, and protects transmitted data against man-in-the-middle attacks.
 
 ## Monitoring

doc/integration/saml.md

@@ -732,7 +732,7 @@ The [Generated passwords for users created through integrated authentication](..
 
 ## Link SAML identity for an existing user
 
-A user can manually link their SAML identity to an existing GitLab account by following the steps in 
+A user can manually link their SAML identity to an existing GitLab account by following the steps in
 [Enable OmniAuth for an existing user](omniauth.md#enable-omniauth-for-an-existing-user).
 
 ## Configuring Group SAML on a self-managed GitLab instance **(PREMIUM SELF)**

doc/topics/offline/quick_start_guide.md

@@ -14,18 +14,18 @@ instance entirely offline.
 NOTE:
 This guide assumes the server is Ubuntu 20.04 using the [Omnibus installation method](https://docs.gitlab.com/omnibus/) and will be running GitLab [Enterprise Edition](https://about.gitlab.com/install/ce-or-ee/). Instructions for other servers may vary.
 This guide also assumes the server host resolves as `my-host.internal`, which you should replace with your
-server's FQDN, and that you have access to a different server with Internet access to download the required package files. 
+server's FQDN, and that you have access to a different server with Internet access to download the required package files.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For a video walkthrough of this process, see [Offline GitLab Installation: Downloading & Installing](https://www.youtube.com/watch?v=TJaq4ua2Prw).
 
 ### Download the GitLab package
 
-You should [manually download the GitLab package](../../update/package/index.md#upgrade-using-a-manually-downloaded-package) and relevant dependencies using a server of the same operating system type that has access to the Internet. 
+You should [manually download the GitLab package](../../update/package/index.md#upgrade-using-a-manually-downloaded-package) and relevant dependencies using a server of the same operating system type that has access to the Internet.
 
-If your offline environment has no local network access, you must manually transport across the relevant package files through physical media, such as a USB drive or writable DVD. 
+If your offline environment has no local network access, you must manually transport across the relevant package files through physical media, such as a USB drive or writable DVD.
 
-In Ubuntu, this can be performed on a server with Internet access using the following commands: 
+In Ubuntu, this can be performed on a server with Internet access using the following commands:
 
 ```shell
 # Download the bash script to prepare the repository
@@ -42,7 +42,7 @@ sudo cp /var/cache/apt/archives/*.deb /path/to/mount
 
 Prerequisites:
 
-- Before installing the GitLab package on your offline environment, ensure that you have installed all required dependencies first. 
+- Before installing the GitLab package on your offline environment, ensure that you have installed all required dependencies first.
 
 If you are using Ubuntu, you can install the dependency `.deb` packages you copied across with `dpkg`. Do not install the GitLab package yet.
 
@@ -202,7 +202,7 @@ done.
 ### Disable Version Check and Service Ping
 
 The Version Check and Service Ping services improve the GitLab user experience and ensure that
-users are on the most up-to-date instances of GitLab. These two services can be turned off for air-gapped 
+users are on the most up-to-date instances of GitLab. These two services can be turned off for air-gapped
 environments so that they do not attempt and fail to reach out to GitLab services.
 
 Learn more about [disabling usage statistics](../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics).

doc/user/application_security/sast/index.md

@@ -399,7 +399,7 @@ and `value` of identifiers and then overridden:
 ```
 
 If a vulnerability is found with a type `CWE` with a value of `703` then
-the vulnerability severity is overwritten to `Critical`. 
+the vulnerability severity is overwritten to `Critical`.
 
 #### Synthesize a custom configuration
 

doc/user/application_security/vulnerabilities/index.md

@@ -28,7 +28,7 @@ On the vulnerability's page, you can:
 - [Create an issue](#create-an-issue-for-a-vulnerability).
 - [Link issues to the vulnerability](#linked-issues).
 - [Resolve a vulnerability](#resolve-a-vulnerability) if a solution is
-  available. 
+  available.
 - [View security training specific to the detected vulnerability](#view-security-training-for-a-vulnerability).
 
 ## Vulnerability status values

doc/user/application_security/vulnerability_report/index.md

@@ -225,8 +225,8 @@ To undo this action, select a different status from the same menu.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/301003) in GitLab 14.9. Disabled by default.
 
 FLAG:
-This feature is not enabled by default. To make it available, ask an administrator to 
-[enable the feature flag](../../feature_flags.md) named `new_vulnerability_form`. 
+This feature is not enabled by default. To make it available, ask an administrator to
+[enable the feature flag](../../feature_flags.md) named `new_vulnerability_form`.
 On GitLab.com, this feature is not yet available.
 
 To add a new vulnerability finding from your project level Vulnerability Report page:
@@ -236,7 +236,7 @@ To add a new vulnerability finding from your project level Vulnerability Report
 1. Click on **Submit Vulnerability**.
 1. Complete the fields and submit the form.
 
-You will be brought to the newly created vulnerability's detail page. Manually created records appear in the 
+You will be brought to the newly created vulnerability's detail page. Manually created records appear in the
 Group, Project, and Security Center Vulnerability Reports. To filter them, use the Generic Tool filter.
 
 ## Operational vulnerabilities

doc/user/clusters/agent/ci_cd_tunnel.md

@@ -123,7 +123,7 @@ Run `kubectl config get-contexts`.
 When you deploy to an environment that has both a [certificate-based
 cluster](../../infrastructure/clusters/index.md) (deprecated) and an agent connection:
 
-- The certificate-based cluster's context is called `gitlab-deploy`. This context 
+- The certificate-based cluster's context is called `gitlab-deploy`. This context
   is always selected by default.
 - In GitLab 14.9 and later, agent contexts are included in the
   `KUBECONFIG`. You can select them by using `kubectl config use-context

doc/user/clusters/agent/index.md

@@ -14,7 +14,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Renamed](https://gitlab.com/groups/gitlab-org/-/epics/7167) from "GitLab Kubernetes Agent" to "GitLab agent for Kubernetes" in GitLab 14.6.
 
 You can connect your Kubernetes cluster with GitLab to deploy, manage,
-and monitor your cloud-native solutions. 
+and monitor your cloud-native solutions.
 
 To connect a Kubernetes cluster to GitLab, you must first [install an agent in your cluster](install/index.md).
 

doc/user/crm/index.md

@@ -188,7 +188,7 @@ When you move an issue, project, or group **within the same group hierarchy**,
 issues retain their contacts.
 
 When you move an issue or project and the **root group changes**,
-issues lose their contacts. 
+issues lose their contacts.
 
 When you move a group and its **root group changes**:
 

doc/user/group/settings/group_access_tokens.md

@@ -24,7 +24,7 @@ Group access tokens are similar to [project access tokens](../../project/setting
 and [personal access tokens](../../profile/personal_access_tokens.md), except they are
 associated with a group rather than a project or user.
 
-In self-managed instances, group access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens) as personal access tokens if the limit is set. 
+In self-managed instances, group access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-personal-access-tokens) as personal access tokens if the limit is set.
 
 You can use group access tokens:
 

doc/user/group/value_stream_analytics/index.md

@@ -125,7 +125,7 @@ To view deployment metrics, you must have a
 [production environment configured](../../../ci/environments/index.md#deployment-tier-of-environments).
 
 Value stream analytics shows the following deployment metrics for your group:  
- 
+
 - Deploys: The number of successful deployments in the date range.
 - Deployment Frequency: The average number of successful deployments per day in the date range.
 
@@ -190,19 +190,19 @@ Each stage of value stream analytics is further described in the table below.
 
 ## Example workflow
 
-This example shows a workflow through all seven stages in one day. 
+This example shows a workflow through all seven stages in one day.
 
-If a stage does not include a start and a stop time, its data is not included in the median time. 
+If a stage does not include a start and a stop time, its data is not included in the median time.
 In this example, milestones have been created and CI/CD for testing and setting environments is configured.
 
 - 09:00: Create issue. **Issue** stage starts.
-- 11:00: Add issue to a milestone, start work on the issue, and create a branch locally. 
-  **Issue** stage stops and **Plan** stage starts. 
+- 11:00: Add issue to a milestone, start work on the issue, and create a branch locally.
+  **Issue** stage stops and **Plan** stage starts.
 - 12:00: Make the first commit.
 - 12:30: Make the second commit to the branch that mentions the issue number.
   **Plan** stage stops and **Code** stage starts.
-- 14:00: Push branch and create a merge request that contains the 
-  [issue closing pattern](../../project/issues/managing_issues.md#closing-issues-automatically). 
+- 14:00: Push branch and create a merge request that contains the
+  [issue closing pattern](../../project/issues/managing_issues.md#closing-issues-automatically).
   **Code** stage stops and **Test** and **Review** stages start.
 - GitLab CI/CD takes 5 minutes to run scripts defined in [`.gitlab-ci.yml`](../../../ci/yaml/index.md).
 - 19:00: Merge the merge request. **Review** stage stops and **Staging** stage starts.
@@ -214,7 +214,7 @@ Value stream analytics records the following times for each stage:
 - **Plan**: 11:00 to 12:00: 1 hr
 - **Code**: 12:00 to 14:00: 2 hrs
 - **Test**: 5 minutes
-- **Review**: 14:00 to 19:00: 5 hrs 
+- **Review**: 14:00 to 19:00: 5 hrs
 - **Staging**: 19:00 to 19:30: 30 minutes
 
 There are some additional considerations for this example:

doc/user/infrastructure/clusters/deploy/inventory_object.md

@@ -23,7 +23,7 @@ gitops:
     default_namespace: my-ns
 ```
 
-The agent creates an inventory object for every item in the `manifest_projects` list. 
+The agent creates an inventory object for every item in the `manifest_projects` list.
 The inventory object is stored in the namespace you specify for `default_namespace`.
 
 The name and location of the inventory object is based on:
@@ -58,7 +58,7 @@ This action changes the location of the object in the cluster.
    inventory objects in the same namespace in the future.
 1. Ensure the value for `cli-utils.sigs.k8s.io/inventory-id` is unique. This value is used for objects
    tracked by this inventory object. Their `config.k8s.io/owning-inventory` annotation is set to this value.
-   
+
    The value doesn't have to match the `name` but it's convenient to set them to the same value.
 
 1. Save the file with the manifest files as a single logical group.

doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md

@@ -18,7 +18,7 @@ in GitLab 14.5. It is expected to be
 [turned off by default in 15.0](../../../update/deprecations.md#certificate-based-integration-with-kubernetes)
 and removed in GitLab 15.6.
 
-If you are using the certificate-based integration, you should move to another workflow as soon as possible. 
+If you are using the certificate-based integration, you should move to another workflow as soon as possible.
 
 As a general rule, to migrate clusters that rely on GitLab CI/CD,
 you can use the [CI/CD workflow](../../clusters/agent/ci_cd_tunnel.md).

doc/user/packages/container_registry/index.md

@@ -698,7 +698,7 @@ Follow [this issue](https://gitlab.com/gitlab-org/container-registry/-/issues/55
 
 ### Tags temporarily cannot be marked for deletion
 
-GitLab is [migrating to the next generation of the Container Registry](https://gitlab.com/groups/gitlab-org/-/epics/5523). 
-During the migration, you may encounter difficulty deleting tags. 
-If you encounter an error, it's likely that your image repository is in the process of being migrated. 
+GitLab is [migrating to the next generation of the Container Registry](https://gitlab.com/groups/gitlab-org/-/epics/5523).
+During the migration, you may encounter difficulty deleting tags.
+If you encounter an error, it's likely that your image repository is in the process of being migrated.
 Please wait a few minutes and try again.

doc/user/project/import/bitbucket.md

@@ -49,7 +49,7 @@ The importer will create any new namespaces (groups) if they don't exist or in
 the case the namespace is taken, the repository will be imported under the user's
 namespace that started the import process.
 
-## Requirements for user-mapped contributions 
+## Requirements for user-mapped contributions
 
 For user contributions to be mapped, each user must complete the following before the project import:
 
@@ -83,7 +83,7 @@ For user contributions to be mapped, each user must complete the following befor
 
 ### If you have more than one Bitbucket account
 
-Be sure to sign in to the correct account. 
+Be sure to sign in to the correct account.
 
 If you've accidentally started the import process with the wrong account, follow these steps:
 

doc/user/project/integrations/harbor.md

@@ -45,7 +45,7 @@ After the Harbor integration is activated:
 ## Secure your requests to the Harbor APIs
 
 For each API request through the Harbor integration, the credentials for your connection to the Harbor API use
-the `username:password` combination. The following are suggestions for safe use: 
+the `username:password` combination. The following are suggestions for safe use:
 
 - Use TLS on the Harbor APIs you connect to.
 - Follow the principle of least privilege (for access on Harbor) with your credentials.

doc/user/project/integrations/webhooks.md

@@ -246,7 +246,7 @@ To view the table:
    - **Fails to connect** if it is temporarily disabled and will retry later.
   
    ![Badges on failing webhooks](img/failed_badges.png)
-   
+
 1. Select **Edit** for the webhook you want to view.
 
 The table includes the following details about each request:

doc/user/project/working_with_projects.md

@@ -79,9 +79,9 @@ To create a project in GitLab:
      from a different repository. Contact your GitLab administrator if this option is not available.
    - [Connect an external repository to GitLab CI/CD](../../ci/ci_cd_for_external_repos/index.md).
 
-- For a list of words that you cannot use as project names, see 
+- For a list of words that you cannot use as project names, see
   [reserved project and group names](../../user/reserved_names.md).
-- For a list of characters that you cannot use in project and group names, see 
+- For a list of characters that you cannot use in project and group names, see
   [limitations on project and group names](../../user/reserved_names.md#limitations-on-project-and-group-names).
 
 ## Create a blank project
@@ -299,7 +299,7 @@ To delete a project:
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/351556) in GitLab 14.9. [Feature flag `project_owners_list_project_pending_deletion`](https://gitlab.com/gitlab-org/gitlab/-/issues/351556) removed.
 
 When delayed project deletion is [enabled for a group](../group/index.md#enable-delayed-project-deletion),
-projects within that group are not deleted immediately, but only after a delay. 
+projects within that group are not deleted immediately, but only after a delay.
 
 To view a list of all projects that are pending deletion:
 

doc/user/reserved_names.md

@@ -19,7 +19,7 @@ under the `TOP_LEVEL_ROUTES`, `PROJECT_WILDCARD_ROUTES` and `GROUP_ROUTES` lists
 
 ## Limitations on project and group names
 
-- Special characters are not permitted at the start or end of project or group names. They are permitted in any other location of the name. 
+- Special characters are not permitted at the start or end of project or group names. They are permitted in any other location of the name.
 - Project or group names cannot end in `.git` or `.atom`.
 - Project or group names can only contain letters, digits, emojis, "_", ".", "+", dashes, or spaces.
 - Paths can only contain letters, digits, "_", "-", and "."