Merge branch 'docs-aqualls-spllllling' into 'master'

Fix more spelling issues in the docs

See merge request gitlab-org/gitlab!53302

doc/.vale/gitlab/spelling-exceptions.txt

@@ -103,6 +103,7 @@ Conda
 Consul
 Contentful
 Corosync
+Coursier
 cron
 crons
 crontab
@@ -150,6 +151,7 @@ Divio
 Dockerfile
 Dockerfiles
 Dockerize
+Dockerized
 Dockerizing
 dogfood
 dogfooding
@@ -376,6 +378,7 @@ passwordless
 Patroni
 performant
 PgBouncer
+pgLoader
 Phabricator
 phaser
 phasers
@@ -484,6 +487,7 @@ rsync
 rsynced
 rsyncing
 rsyncs
+Rubinius
 Rubix
 Rubocop
 Rubular
@@ -596,6 +600,8 @@ Tokenizers
 tokenizing
 toolchain
 toolchains
+toolkit
+toolkits
 tooltip
 tooltips
 transpile
@@ -699,9 +705,11 @@ unverifying
 uploader
 uploaders
 upstreams
+upvote
 upvoted
 upvotes
 URIs
+Vagrantfile
 validator
 validators
 vendored

doc/development/utilities.md

@@ -117,9 +117,8 @@ regular Ruby module.
 
 Since we already have `Prependable` as a patch for `ActiveSupport::Concern`
 to enable `prepend`, it has consequences with how it would interact with
-`override` and `class_methods`. We add a workaround directly into
-`Prependable` to resolve the problem, by `extend`ing `ClassMethods` into the
-defining module.
+`override` and `class_methods`. As a workaround, `extend` `ClassMethods`
+into the defining `Prependable` module.
 
 This allows us to use `override` to verify `class_methods` used in the
 context mentioned above. This workaround only applies when we run the

doc/install/README.md

@@ -24,7 +24,7 @@ install GitLab:
   The cloud native Helm chart for installing GitLab and all of its components
   on Kubernetes.
 - [_Docker_](#installing-gitlab-with-docker): The Omnibus GitLab packages,
-  dockerized.
+  Dockerized.
 - [_Source_](#installing-gitlab-from-source): Install GitLab and all of its
   components from scratch.
 - [_Cloud provider_](#installing-gitlab-on-cloud-providers): Install directly

doc/install/installation.md

@@ -172,8 +172,12 @@ sudo apt-get install -y postfix
 
 Then select 'Internet Site' and press enter to confirm the hostname.
 
+<!-- vale gitlab.Spelling = NO -->
+
 ### Exiftool
 
+<!-- vale gitlab.Spelling = YES -->
+
 [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse#dependencies)
 requires `exiftool` to remove EXIF data from uploaded images.
 
@@ -187,7 +191,7 @@ The Ruby interpreter is required to run GitLab.
 See the [requirements page](requirements.md#ruby-versions) for the minimum
 Ruby requirements.
 
-The use of Ruby version managers such as [RVM](https://rvm.io/), [rbenv](https://github.com/rbenv/rbenv) or [chruby](https://github.com/postmodern/chruby) with GitLab
+The use of Ruby version managers such as [`RVM`](https://rvm.io/), [`rbenv`](https://github.com/rbenv/rbenv) or [`chruby`](https://github.com/postmodern/chruby) with GitLab
 in production, frequently leads to hard to diagnose problems. Version managers
 are not supported and we strongly advise everyone to follow the instructions
 below to use a system Ruby.
@@ -241,7 +245,7 @@ requirements for these are:
 - `node` >= v10.14.2. (We recommend node 14.x as it is faster)
 - `yarn` >= v1.10.0.
 
-In many distros,
+In many distributions,
 the versions provided by the official package repositories are out of date, so
 we need to install through the following commands:
 
@@ -935,7 +939,7 @@ production:
   url: redis://redis.example.tld:6379
 ```
 
-If you want to connect the Redis server via socket, use the "unix:" URL scheme and the path to the Redis socket file in the `config/resque.yml` file.
+If you want to connect the Redis server via socket, use the `unix:` URL scheme and the path to the Redis socket file in the `config/resque.yml` file.
 
 ```yaml
 # example

doc/install/openshift_and_gitlab/index.md

@@ -15,7 +15,7 @@ for details.
 
 ## Introduction
 
-[OpenShift Origin](https://www.okd.io/) (**Note:** renamed to OKD in Aug 2018) is an open source container application
+[OpenShift Origin](https://www.okd.io/) (**Note:** renamed to OKD in August 2018) is an open source container application
 platform created by [RedHat](https://www.redhat.com/en), based on [Kubernetes](https://kubernetes.io/) and [Docker](https://www.docker.com). That means
 you can host your own PaaS for free and almost with no hassle.
 
@@ -44,7 +44,7 @@ test OpenShift easily:
 It is also important to mention that for the purposes of this tutorial, the
 latest Origin release is used:
 
-- **oc** `v1.3.0` (must be [installed](https://github.com/openshift/origin/releases/tag/v1.3.0) locally on your computer)
+- **`oc`** `v1.3.0` (must be [installed](https://github.com/openshift/origin/releases/tag/v1.3.0) locally on your computer)
 - **OpenShift** `v1.3.0` (is pre-installed in the [VM image](https://app.vagrantup.com/openshift/boxes/origin-all-in-one))
 - **Kubernetes** `v1.3.0` (is pre-installed in the [VM image](https://app.vagrantup.com/openshift/boxes/origin-all-in-one))
 
@@ -59,8 +59,8 @@ on your computer.
 
 ## Getting familiar with OpenShift Origin
 
-The environment we are about to use is based on CentOS 7 which comes with all
-the tools needed pre-installed: Docker, Kubernetes, OpenShift, etcd.
+The environment we are about to use is based on CentOS 7, which comes with all
+the tools needed pre-installed, including Docker, Kubernetes, and OpenShift.
 
 ### Test OpenShift using Vagrant
 
@@ -100,14 +100,14 @@ order to proceed.
 Let's login as admin with username/password `admin/admin`. This is what the
 landing page looks like:
 
-![openshift web console](img/web-console.png)
+![OpenShift web console](img/web-console.png)
 
 You can see that a number of [projects](https://docs.okd.io/3.11/dev_guide/projects.html) are already created for testing purposes.
 
 If you head over the `openshift-infra` project, a number of services with their
 respective pods are there to explore.
 
-![openshift web console](img/openshift-infra-project.png)
+![OpenShift web console](img/openshift-infra-project.png)
 
 We are not going to explore the whole interface, but if you want to learn about
 the key concepts of OpenShift, read the [core concepts reference](https://docs.okd.io/3.11/architecture/core_concepts/index.html)
@@ -318,7 +318,7 @@ NOTE:
 The `gitlab.apps.10.2.2.2.nip.io` hostname that is used by default will
 resolve to the host with IP `10.2.2.2` which is the IP our VM uses. It is a
 trick to have distinct FQDNs pointing to services that are on our local network.
-Read more on how this works in <https://nip.io>.
+Read more on how this works at [nip.io](https://nip.io).
 
 Now that we configured this, let's see how to manage and scale GitLab.
 
@@ -343,7 +343,7 @@ created the GitLab app? This is where you can see them in action.
 
 ![Running pods](img/running-pods.png)
 
-You can see GitLab being reconfigured by taking look at the logs in realtime.
+You can see GitLab being reconfigured by taking look at the logs in real time.
 Click on `gitlab-ce-2-j7ioe` (your ID will be different) and go to the **Logs**
 tab.
 
@@ -464,7 +464,7 @@ OpenShift's website about [autoscaling](https://docs.okd.io/3.11/dev_guide/pod_a
 As stated in the [all-in-one VM](https://www.okd.io/minishift/) page:
 
 > By default, OpenShift will not allow a container to run as root or even a
-non-random container assigned userid. Most Docker images in Docker Hub do not
+non-random container assigned user ID. Most Docker images in Docker Hub do not
 follow this best practice and instead run as root.
 
 The all-in-one VM we are using has this security turned off so it will not

doc/install/requirements.md

@@ -179,7 +179,7 @@ Omnibus GitLab defaults to the recommended Puma settings. Regardless of installa
 tune the Puma settings.
 
 If you're using Omnibus GitLab, see [Puma settings](https://docs.gitlab.com/omnibus/settings/puma.html)
-for instructions on changing the Puma settings. If you're using the GitLab Helm chart, see the [Webservice chart](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
+for instructions on changing the Puma settings. If you're using the GitLab Helm chart, see the [`webservice` chart](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
 
 ### Puma workers
 
@@ -227,7 +227,7 @@ recommendation above) please see [the Unicorn settings in the Omnibus GitLab doc
 
 Redis stores all user sessions and the background task queue.
 The storage requirements for Redis are minimal, about 25kB per user.
-Sidekiq processes the background jobs with a multithreaded process.
+Sidekiq processes the background jobs with a multi-threaded process.
 This process starts with the entire Rails stack (200MB+) but it can grow over time due to memory leaks.
 On a very active server (10,000 billable users) the Sidekiq process can use 1GB+ of memory.
 

doc/integration/vault.md

@@ -44,7 +44,7 @@ The following assumes you already have Vault installed and running.
    Success! Enabled oidc auth method at: oidc/
    ```
 
-1. **Write the OIDC config:**
+1. **Write the OIDC configuration:**
 
    Next, Vault needs to be given the application ID and secret generated by GitLab.
 
@@ -67,7 +67,7 @@ The following assumes you already have Vault installed and running.
    Success! Data written to: auth/oidc/config
    ```
 
-1. **Write the OIDC Role Config:**
+1. **Write the OIDC Role Configuration:**
 
    Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
 
@@ -108,7 +108,7 @@ The following assumes you already have Vault installed and running.
 
    Here's a short explanation of what this command does:
 
-   1. In the **Write the OIDC Role Config** (step 4), we created a role called
+   1. In the **Write the OIDC Role Configuration** (step 4), we created a role called
       `demo`. We set `role=demo` so Vault knows which configuration we'd like to
       sign in with.
    1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.

doc/push_rules/push_rules.md

@@ -92,7 +92,7 @@ The following options are available:
 | Check whether the commit author is a GitLab user | Restrict commits to existing GitLab users (checked against their emails). |
 | Reject unverified users **(PREMIUM)** | GitLab rejects any commit that was not committed by an authenticated user. |
 | Check whether commit is signed through GPG **(PREMIUM)** | Reject commit when it is not signed through GPG. Read [signing commits with GPG](../user/project/repository/gpg_signed_commits/index.md). |
-| Prevent pushing secret files | GitLab rejects any files that are likely to contain secrets. See the [forbiden file names](#prevent-pushing-secrets-to-the-repository). |
+| Prevent pushing secret files | GitLab rejects any files that are likely to contain secrets. See the [forbidden file names](#prevent-pushing-secrets-to-the-repository). |
 | Require expression in commit messages | Only commit messages that match this regular expression are allowed to be pushed. Leave empty to allow any commit message. Uses multiline mode, which can be disabled using `(?-m)`. |
 | Reject expression in commit messages | Only commit messages that do not match this regular expression are allowed to be pushed. Leave empty to allow any commit message. Uses multiline mode, which can be disabled using `(?-m)`. |
 | Restrict by branch name | Only branch names that match this regular expression are allowed to be pushed. Leave empty to allow any branch name. |

doc/security/cicd_environment_variables.md

@@ -8,6 +8,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Environment variables are applied to environments via the runner and can be set from the project's **Settings > CI/CD** page.
 
-The values are encrypted using [aes-256-cbc](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and stored in the database.
+The values are encrypted using [`aes-256-cbc`](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and stored in the database.
 
 This data can only be decrypted with a valid [secrets file](../raketasks/backup_restore.md#when-the-secrets-file-is-lost).

doc/security/crime_vulnerability.md

@@ -58,7 +58,7 @@ vulnerability.
 
 ## References
 
-- NGINX ["Module ngx_http_spdy_module"](http://nginx.org/en/docs/http/ngx_http_spdy_module.html)
+- NGINX ["Module `ngx_http_spdy_module`"](http://nginx.org/en/docs/http/ngx_http_spdy_module.html)
 - Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"](https://www.tenable.com/plugins/index.php?view=single&id=62565)
 - Wikipedia contributors, ["CRIME"](https://en.wikipedia.org/wiki/CRIME) Wikipedia, The Free Encyclopedia
 

doc/update/mysql_to_postgresql.md

@@ -15,7 +15,7 @@ NOTE:
 Support for MySQL was removed in GitLab 12.1. This procedure should be performed
 **before** installing GitLab 12.1.
 
-[pgloader](https://pgloader.io/) 3.4.1+ is required, confirm with `pgloader -V`.
+[pgLoader](https://pgloader.io/) 3.4.1+ is required, confirm with `pgloader -V`.
 
 You can install it directly from your distribution, for example in
 Debian/Ubuntu:
@@ -52,7 +52,7 @@ For other distributions, follow the instructions in PostgreSQL's
 and then install `pgloader`.
 
 If you are migrating to a Docker based installation, you must install
-pgloader within the container as it is not included in the container image.
+pgLoader within the container as it is not included in the container image.
 
 1. Start a shell session in the context of the running container:
 
@@ -60,7 +60,7 @@ pgloader within the container as it is not included in the container image.
    docker exec -it gitlab bash
    ```
 
-1. Install pgloader:
+1. Install pgLoader:
 
    ```shell
    apt-get update