Remove NBSP spaces from docs

We don't need NBSP spaces in the docs, and they
can cause trouble when linting and using grep
as they will not match on searches for spaces

doc/development/database_review.md

@@ -201,8 +201,8 @@ estimated to keep migration timing to a minimum.
 NOTE: **Note:**
 Keep in mind that all runtimes should be measured against GitLab.com.
 
-| Migration Type | Execution Time Recommended | Notes |
+| Migration Type | Execution Time Recommended | Notes |
 |----|----|---|
 | Regular migrations on `db/migrate` | `3 minutes` | A valid exception are index creation as this can take a long time. |
-| Post migrations on `db/post_migrate` | `10 minutes` | |
-| Background migrations | --- | Since these are suitable for larger tables, it's not possible to set a precise timing guideline, however, any single query must stay below `1 second` execution time with cold caches. |
+| Post migrations on `db/post_migrate` | `10 minutes` | |
+| Background migrations | --- | Since these are suitable for larger tables, it's not possible to set a precise timing guideline, however, any single query must stay below `1 second` execution time with cold caches. |

doc/development/documentation/styleguide.md

@@ -1208,10 +1208,10 @@ When you take screenshots:
   or concept in the image. If the image is of the GitLab interface, append the
   GitLab version to the file name, based on the following format:
   `image_name_vX_Y.png`. For example, for a screenshot taken from the pipelines
-  page of GitLab 11.1, a valid name is `pipelines_v11_1.png`. If you're adding an
+  page of GitLab 11.1, a valid name is `pipelines_v11_1.png`. If you're adding an
   illustration that doesn't include parts of the user interface, add the release
   number corresponding to the release the image was added to; for an MR added to
-  11.1's milestone, a valid name for an illustration is `devops_diagram_v11_1.png`.
+  11.1's milestone, a valid name for an illustration is `devops_diagram_v11_1.png`.
 - Place images in a separate directory named `img/` in the same directory where
   the `.md` document that you're working on is located.
 - Consider using PNG images instead of JPEG.

doc/development/git_object_deduplication.md

@@ -162,7 +162,7 @@ repository and a pool.
 
 ### Pool existence
 
-If GitLab thinks a pool repository exists (i.e. it exists according to
+If GitLab thinks a pool repository exists (i.e. it exists according to
 SQL), but it does not on the Gitaly server, then it will be created on
 the fly by Gitaly.
 

doc/development/i18n/translation.md

@@ -100,7 +100,7 @@ To propose additions to the glossary please
 ### Inclusive language in French
 
 <!-- vale gitlab.Spelling = NO -->
-In French, the "écriture inclusive" is now over (see on [Legifrance](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000036068906&categorieLien=id)).
+In French, the "écriture inclusive" is now over (see on [Legifrance](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000036068906&categorieLien=id)).
 So, to include both genders, write “Utilisateurs et utilisatrices” instead of “Utilisateur·rice·s”.
 When space is missing, the male gender should be used alone.
 <!-- vale gitlab.Spelling = YES -->

doc/development/import_export.md

@@ -360,28 +360,28 @@ The NDJSON tree will look like this:
 ```shell
 tree
 ├── project
-│   ├── auto_devops.ndjson
-│   ├── boards.ndjson
-│   ├── ci_cd_settings.ndjson
-│   ├── ci_pipelines.ndjson
-│   ├── container_expiration_policy.ndjson
-│   ├── custom_attributes.ndjson
-│   ├── error_tracking_setting.ndjson
-│   ├── external_pull_requests.ndjson
-│   ├── issues.ndjson
-│   ├── labels.ndjson
-│   ├── merge_requests.ndjson
-│   ├── milestones.ndjson
-│   ├── pipeline_schedules.ndjson
-│   ├── project_badges.ndjson
-│   ├── project_feature.ndjson
-│   ├── project_members.ndjson
-│   ├── protected_branches.ndjson
-│   ├── protected_tags.ndjson
-│   ├── releases.ndjson
-│   ├── services.ndjson
-│   ├── snippets.ndjson
-│   └── triggers.ndjson
+│   ├── auto_devops.ndjson
+│   ├── boards.ndjson
+│   ├── ci_cd_settings.ndjson
+│   ├── ci_pipelines.ndjson
+│   ├── container_expiration_policy.ndjson
+│   ├── custom_attributes.ndjson
+│   ├── error_tracking_setting.ndjson
+│   ├── external_pull_requests.ndjson
+│   ├── issues.ndjson
+│   ├── labels.ndjson
+│   ├── merge_requests.ndjson
+│   ├── milestones.ndjson
+│   ├── pipeline_schedules.ndjson
+│   ├── project_badges.ndjson
+│   ├── project_feature.ndjson
+│   ├── project_members.ndjson
+│   ├── protected_branches.ndjson
+│   ├── protected_tags.ndjson
+│   ├── releases.ndjson
+│   ├── services.ndjson
+│   ├── snippets.ndjson
+│   └── triggers.ndjson
 └── project.json
 ```
 
@@ -395,19 +395,19 @@ The NDJSON tree will look like this:
 tree
 └── groups
     ├── 4351
-    │   ├── badges.ndjson
-    │   ├── boards.ndjson
-    │   ├── epics.ndjson
-    │   ├── labels.ndjson
-    │   ├── members.ndjson
-    │   └── milestones.ndjson
+    │   ├── badges.ndjson
+    │   ├── boards.ndjson
+    │   ├── epics.ndjson
+    │   ├── labels.ndjson
+    │   ├── members.ndjson
+    │   └── milestones.ndjson
     ├── 4352
-    │   ├── badges.ndjson
-    │   ├── boards.ndjson
-    │   ├── epics.ndjson
-    │   ├── labels.ndjson
-    │   ├── members.ndjson
-    │   └── milestones.ndjson
+    │   ├── badges.ndjson
+    │   ├── boards.ndjson
+    │   ├── epics.ndjson
+    │   ├── labels.ndjson
+    │   ├── members.ndjson
+    │   └── milestones.ndjson
     ├── _all.ndjson
     ├── 4351.json
     └── 4352.json

doc/development/integrations/secure.md

@@ -256,7 +256,7 @@ to `info`.
 
 When executing command lines, scanners should use the `debug` level to log the command line and its output.
 For instance, the [bundler-audit](https://gitlab.com/gitlab-org/security-products/analyzers/bundler-audit) scanner
-uses the `debug` level to log the command line `bundle audit check --quiet`,
+uses the `debug` level to log the command line `bundle audit check --quiet`,
 and what `bundle audit` writes to the standard output.
 
 #### common logutil package
@@ -298,7 +298,7 @@ The `vulnerabilities` field of the report is an array of vulnerability objects.
 
 #### ID
 
-The `id` field is the unique identifier of the vulnerability.
+The `id` field is the unique identifier of the vulnerability.
 It is used to reference a fixed vulnerability from a [remediation objects](#remediations).
 We recommend that you generate a UUID and use it as the `id` field's value.
 

doc/development/namespaces_storage_statistics.md

@@ -6,18 +6,18 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Database case study: Namespaces storage statistics
 
-## Introduction
+## Introduction
 
 On [Storage and limits management for groups](https://gitlab.com/groups/gitlab-org/-/epics/886),
 we want to facilitate a method for easily viewing the amount of
 storage consumed by a group, and allow easy management.
 
-## Proposal
+## Proposal
 
 1. Create a new ActiveRecord model to hold the namespaces' statistics in an aggregated form (only for root namespaces).
 1. Refresh the statistics in this model every time a project belonging to this namespace is changed.
 
-## Problem
+## Problem
 
 In GitLab, we update the project storage statistics through a
 [callback](https://gitlab.com/gitlab-org/gitlab/blob/4ab54c2233e91f60a80e5b6fa2181e6899fdcc3e/app/models/project.rb#L97)
@@ -42,7 +42,7 @@ alternative method.
 
 ## Attempts
 
-### Attempt A: PostgreSQL materialized view
+### Attempt A: PostgreSQL materialized view
 
 Model can be updated through a refresh strategy based on a project routes SQL and a [materialized view](https://www.postgresql.org/docs/11/rules-materializedviews.html):
 
@@ -71,7 +71,7 @@ While this implied a single query update (and probably a fast one), it has some
 - Materialized views syntax varies from PostgreSQL and MySQL. While this feature was worked on, MySQL was still supported by GitLab.
 - Rails does not have native support for materialized views. We'd need to use a specialized gem to take care of the management of the database views, which implies additional work.
 
-### Attempt B: An update through a CTE
+### Attempt B: An update through a CTE
 
 Similar to Attempt A: Model update done through a refresh strategy with a [Common Table Expression](https://www.postgresql.org/docs/9.1/queries-with.html)
 
@@ -140,7 +140,7 @@ Even though this approach would make aggregating much easier, it has some major
 - We'd have to migrate **all namespaces** by adding and filling a new column. Because of the size of the table, dealing with time/cost will not be great. The background migration will take approximately `153h`, see <https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29772>.
 - Background migration has to be shipped one release before, delaying the functionality by another milestone.
 
-### Attempt E (final): Update the namespace storage statistics in async way
+### Attempt E (final): Update the namespace storage statistics in async way
 
 This approach consists of keep using the incremental statistics updates we currently already have,
 but we refresh them through Sidekiq jobs and in different transactions:
@@ -170,7 +170,7 @@ The only downside of this approach is that namespaces' statistics are updated up
 which means there's a time window in which the statistics are inaccurate. Because we're still not
 [enforcing storage limits](https://gitlab.com/gitlab-org/gitlab/-/issues/17664), this is not a major problem.
 
-## Conclusion
+## Conclusion
 
 Updating the storage statistics asynchronously, was the less problematic and
 performant approach of aggregating the root namespaces.

doc/policy/maintenance.md

@@ -74,7 +74,7 @@ A step-by-step guide to [upgrading the Omnibus-bundled PostgreSQL is documented
 
 ## Upgrading major versions
 
-Backward-incompatible changes and migrations are reserved for major versions. See the [upgrade guide](../update/README.md#upgrading-to-a-new-major-version).
+Backward-incompatible changes and migrations are reserved for major versions. See the [upgrade guide](../update/README.md#upgrading-to-a-new-major-version).
 
 ## Patch releases
 

doc/update/README.md

@@ -164,7 +164,7 @@ upgrade paths.
 ## Upgrading to a new major version
 
 Upgrading the *major* version requires more attention.
-Backward-incompatible changes and migrations are reserved for major versions.
+Backward-incompatible changes and migrations are reserved for major versions.
 We cannot guarantee that upgrading between major versions will be seamless.
 It is suggested to upgrade to the latest available *minor* version within
 your major version before proceeding to the next major version.

doc/user/application_security/dependency_scanning/index.md

@@ -53,7 +53,7 @@ is **not** `19.03.0`. See [troubleshooting information](#error-response-from-dae
 ## Supported languages and package managers
 
 GitLab relies on [`rules`](../../../ci/yaml/README.md#rules) to start relevant analyzers depending on the languages detected in the repository.
-The current detection logic limits the maximum search depth to two levels. For example, the `gemnasium-dependency_scanning` job is enabled if a repository contains either a `Gemfile` or `api/Gemfile` file, but not if the only supported dependency file is `api/client/Gemfile`.
+The current detection logic limits the maximum search depth to two levels. For example, the `gemnasium-dependency_scanning` job is enabled if a repository contains either a `Gemfile` or `api/Gemfile` file, but not if the only supported dependency file is `api/client/Gemfile`.
 
 The following languages and dependency managers are supported:
 

doc/user/application_security/index.md

@@ -110,7 +110,7 @@ The scanning tools and vulnerabilities database are updated regularly.
 | Secure scanning tool                                         | Vulnerabilities database updates          |
 |:-------------------------------------------------------------|-------------------------------------------|
 | [Container Scanning](container_scanning/index.md)            | Uses `clair`. The latest `clair-db` version is used for each job by running the [`latest` Docker image tag](https://gitlab.com/gitlab-org/gitlab/blob/438a0a56dc0882f22bdd82e700554525f552d91b/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L37). The `clair-db` database [is updated daily according to the author](https://github.com/arminc/clair-local-scan#clair-server-or-local). |
-| [Dependency Scanning](dependency_scanning/index.md)          | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for NPM packages), and `gemnasium` (GitLab's own tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
+| [Dependency Scanning](dependency_scanning/index.md)          | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for NPM packages), and `gemnasium` (GitLab's own tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
 | [Dynamic Application Security Testing (DAST)](dast/index.md) | The scanning engine is updated on a periodic basis. See the [version of the underlying tool `zaproxy`](https://gitlab.com/gitlab-org/security-products/dast/blob/master/Dockerfile#L1). The scanning rules are downloaded at scan runtime. |
 | [Static Application Security Testing (SAST)](sast/index.md)  | Relies exclusively on [the tools GitLab wraps](sast/index.md#supported-languages-and-frameworks). The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools. |
 

doc/user/project/clusters/serverless/aws.md

@@ -335,7 +335,7 @@ Some steps in this documentation use SAM CLI. Follow the instructions for
 [installing SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html)
 to install and configure SAM CLI.
 
-If you use [AWS Cloud9](https://aws.amazon.com/cloud9/) as your integrated development
+If you use [AWS Cloud9](https://aws.amazon.com/cloud9/) as your integrated development
 environment (IDE), the following are installed for you:
 
 - [AWS Command Line Interface](https://docs.aws.amazon.com/en_pv/cli/latest/userguide/cli-chap-install.html)
@@ -357,7 +357,7 @@ To create a new AWS SAM application:
 1. `git push` the application back to the GitLab project.
 
 This creates a SAM app named `gitlabpoc` using the default configuration, a single
-Python 3.8 function invoked by an [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+Python 3.8 function invoked by an [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
 endpoint. To see additional runtimes supported by SAM and options for `sam init`, run:
 
 ```shell
@@ -367,13 +367,13 @@ sam init -h
 ### Setting up your AWS credentials with your GitLab account
 
 In order to interact with your AWS account, the GitLab CI/CD pipelines require both
-`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be set in the project's CI/CD
+`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be set in the project's CI/CD
 variables.
 
 To set these:
 
-1. Navigate to the project's **Settings > CI / CD**.
-1. Expand the **Variables** section and create entries for `AWS_ACCESS_KEY_ID` and
+1. Navigate to the project's **Settings > CI / CD**.
+1. Expand the **Variables** section and create entries for `AWS_ACCESS_KEY_ID` and
    `AWS_SECRET_ACCESS_KEY`.
 1. Mask the credentials so they do not show in logs using the **Masked** toggle.
 
@@ -460,7 +460,7 @@ CLI installed locally for you to test locally.
 
 First, test the function.
 
-SAM provides a default event in `events/event.json` that includes a message body of:
+SAM provides a default event in `events/event.json` that includes a message body of:
 
 ```plaintext
 {\"message\": \"hello world\"}
@@ -491,7 +491,7 @@ sam local start-api
 ```
 
 SAM again launches a Docker container, this time with a mocked Amazon API Gateway
-listening on `localhost:3000`.
+listening on `localhost:3000`.
 
 Call the `hello` API by running:
 

doc/user/project/merge_requests/code_quality.md

@@ -348,7 +348,7 @@ This can be due to multiple reasons:
   nothing will be displayed.
 - The [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in) CI/CD
   setting can cause the Code Quality artifact(s) to expire faster than desired.
-- Large `codeclimate.json` files (esp. >10 MB) are [known to prevent the report from being displayed](https://gitlab.com/gitlab-org/gitlab/-/issues/2737).
+- Large `codeclimate.json` files (esp. >10 MB) are [known to prevent the report from being displayed](https://gitlab.com/gitlab-org/gitlab/-/issues/2737).
   As a work-around, try removing [properties](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types)
   that are [ignored by GitLab](#implementing-a-custom-tool). You can:
   - Configure the Code Quality tool to not output those types.