Merge branch 'docs-20200107-spellchecker' into 'master'

Correcting spelling across many files

See merge request gitlab-org/gitlab!22563

doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md

@@ -23,7 +23,7 @@ For example, [Active Directory](https://docs.microsoft.com/en-us/previous-versio
 - [Oracle Internet Directory](https://www.oracle.com/middleware/technologies/internet-directory.html)
 - [OpenLDAP](http://www.openldap.org/)
 - [389 Directory](http://directory.fedoraproject.org/)
-- [OpenDJ (Renamed to Foregerock Directory Services)](https://www.forgerock.com/platform/directory-services)
+- [OpenDJ (Renamed to Forgerock Directory Services)](https://www.forgerock.com/platform/directory-services)
 - [ApacheDS](https://directory.apache.org/)
 
 > GitLab uses the [Net::LDAP](https://rubygems.org/gems/net-ldap) library under the hood. This means it supports all [IETF](https://tools.ietf.org/html/rfc2251) compliant LDAPv3 servers.

doc/administration/gitaly/index.md

@@ -45,7 +45,7 @@ requiring a shared NFS mount for Git repository data.
 Between 11.4 and 11.8 the exception was the
 [Elasticsearch indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
 But since 11.8 the indexer uses Gitaly for data access as well. NFS can still
-be leveraged for redudancy on block level of the Git data. But only has to
+be leveraged for redundancy on block level of the Git data. But only has to
 be mounted on the Gitaly server.
 
 From GitLab v11.8 to v12.2, it is possible to use Elasticsearch in conjunction with
@@ -618,7 +618,7 @@ This will limit the number of in-flight RPC calls for the given RPC's.
 The limit is applied per repository. In the example above, each on the
 Gitaly server can have at most 20 simultaneous PostUploadPack calls in
 flight, and the same for SSHUploadPack. If another request comes in for
-a repository that hase used up its 20 slots, that request will get
+a repository that has used up its 20 slots, that request will get
 queued.
 
 You can observe the behavior of this queue via the Gitaly logs and via
@@ -762,7 +762,7 @@ Git implementation itself.
 
 Because Rugged+Unicorn was so efficient, GitLab's application code ended
 up with lots of duplicate Git object lookups (like looking up the
-`master` commmit a dozen times in one request). We could write
+`master` commit a dozen times in one request). We could write
 inefficient code without being punished for it.
 
 When we migrated these Git lookups to Gitaly calls, we were suddenly
@@ -927,7 +927,7 @@ Confirm the following are all true:
   ```
 
 - When any user adds or modifies a file from the repository using the GitLab
-  UI, it immediatley fails with a red `401 Unauthorized` banner.
+  UI, it immediately fails with a red `401 Unauthorized` banner.
 - Creating a new project and [initializing it with a README](../../gitlab-basics/create-project.md#blank-projects)
   successfully creates the project but doesn't create the README.
 - When [tailing the logs](https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server) on an app node and reproducing the error, you get `401` errors

doc/administration/gitaly/praefect.md

@@ -31,7 +31,7 @@ graph TB
 ```
 
 Where `GitLab` is the collection of clients that can request Git operations.
-The Praefect node has threestorage nodes attached. Praefect itself doesn't
+The Praefect node has three storage nodes attached. Praefect itself doesn't
 store data, but connects to three Gitaly nodes, `Gitaly-1`,  `Gitaly-2`, and `Gitaly-3`.
 
 Praefect may be enabled on its own node or can be run on the GitLab server.

doc/administration/high_availability/consul.md

@@ -100,7 +100,7 @@ If it is necessary to restart the server cluster, it is important to do this in
 
 To be safe, we recommend you only restart one server agent at a time to ensure the cluster remains intact.
 
-For larger clusters, it is possible to restart multiple agents at a time. See the [Consul consensus document](https://www.consul.io/docs/internals/consensus.html#deployment-table) for how many failures it can tolerate. This will be the number of simulateneous restarts it can sustain.
+For larger clusters, it is possible to restart multiple agents at a time. See the [Consul consensus document](https://www.consul.io/docs/internals/consensus.html#deployment-table) for how many failures it can tolerate. This will be the number of simultaneous restarts it can sustain.
 
 ## Upgrades for bundled Consul
 

doc/administration/job_logs.md

@@ -81,7 +81,7 @@ with one change: _the stored path of the first two phases is different_. This in
 log architecture stores chunks of logs in Redis and a persistent store (object storage or database) instead of
 file storage. Redis is used as first-class storage, and it stores up-to 128KB
 of data. Once the full chunk is sent, it is flushed to a persistent store, either object storage (temporary directory) or database.
-After a while, the data in Redis and a persitent store will be archived to [object storage](#uploading-logs-to-object-storage).
+After a while, the data in Redis and a persistent store will be archived to [object storage](#uploading-logs-to-object-storage).
 
 The data are stored in the following Redis namespace: `Gitlab::Redis::SharedState`.
 

doc/administration/lfs/lfs_administration.md

@@ -238,8 +238,8 @@ and [projects APIs](../../api/projects.md).
 
 ## Troubleshooting: `Google::Apis::TransmissionError: execution expired`
 
-If LFS integration is configred with Google Cloud Storage and background uploads (`background_upload: true` and `direct_upload: false`),
-Sidekiq workers may encouter this error. This is because the uploading timed out with very large files.
+If LFS integration is configured with Google Cloud Storage and background uploads (`background_upload: true` and `direct_upload: false`),
+Sidekiq workers may encounter this error. This is because the uploading timed out with very large files.
 LFS files up to 6Gb can be uploaded without any extra steps, otherwise you need to use the following workaround.
 
 ```shell

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -26,7 +26,7 @@ The following metrics are available:
 | Metric                                                         | Type      |                  Since | Description                                                                                         | Labels                                              |
 |:---------------------------------------------------------------|:----------|-----------------------:|:----------------------------------------------------------------------------------------------------|:----------------------------------------------------|
 | `gitlab_banzai_cached_render_real_duration_seconds`            | Histogram |                    9.4 | Duration of rendering Markdown into HTML when cached output exists                                  | controller, action                                  |
-| `gitlab_banzai_cacheless_render_real_duration_seconds`         | Histogram |                    9.4 | Duration of rendering Markdown into HTML when cached outupt does not exist                          | controller, action                                  |
+| `gitlab_banzai_cacheless_render_real_duration_seconds`         | Histogram |                    9.4 | Duration of rendering Markdown into HTML when cached output does not exist                          | controller, action                                  |
 | `gitlab_cache_misses_total`                                    | Counter   |                   10.2 | Cache read miss                                                                                     | controller, action                                  |
 | `gitlab_cache_operation_duration_seconds`                      | Histogram |                   10.2 | Cache access time                                                                                   |                                                     |
 | `gitlab_cache_operations_total`                                | Counter   |                   12.2 | Cache operations by controller/action                                                               | controller, action, operation                       |
@@ -59,7 +59,7 @@ The following metrics are available:
 | `gitlab_transaction_event_push_commit_total`                   | Counter   |                    9.4 | Counter for commits                                                                                 | branch                                              |
 | `gitlab_transaction_event_push_tag_total`                      | Counter   |                    9.4 | Counter for tag pushes                                                                              |                                                     |
 | `gitlab_transaction_event_rails_exception_total`               | Counter   |                    9.4 | Counter for number of rails exceptions                                                              |                                                     |
-| `gitlab_transaction_event_receive_email_total`                 | Counter   |                    9.4 | Counter for recieved emails                                                                         | handler                                             |
+| `gitlab_transaction_event_receive_email_total`                 | Counter   |                    9.4 | Counter for received emails                                                                         | handler                                             |
 | `gitlab_transaction_event_remote_mirrors_failed_total`         | Counter   |                   10.8 | Counter for failed remote mirrors                                                                   |                                                     |
 | `gitlab_transaction_event_remote_mirrors_finished_total`       | Counter   |                   10.8 | Counter for finished remote mirrors                                                                 |                                                     |
 | `gitlab_transaction_event_remote_mirrors_running_total`        | Counter   |                   10.8 | Counter for running remote mirrors                                                                  |                                                     |

doc/administration/troubleshooting/elasticsearch.md

@@ -325,7 +325,7 @@ feel free to update that page with issues you encounter and solutions.
 
 ## Replication
 
-Setting up Elasticsearch isn't too bad, but it can be a bit finnicky and time consuming.
+Setting up Elasticsearch isn't too bad, but it can be a bit finicky and time consuming.
 
 The easiest method is to spin up a docker container with the required version and
 bind ports 9200/9300 so it can be used.

doc/administration/troubleshooting/postgresql.md

@@ -41,7 +41,7 @@ This section is for links to information elsewhere in the GitLab documentation.
 
 - [Using Slony to update PostgreSQL](../../update/upgrading_postgresql_using_slony.md)
   - Uses replication to handle PostgreSQL upgrades - providing the schemas are the same.
-  - Reduces downtime to a short window for swinging over to the newer vewrsion.
+  - Reduces downtime to a short window for swinging over to the newer version.
 
 - Managing Omnibus PostgreSQL versions [from the development docs](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html)
 

doc/administration/troubleshooting/sidekiq.md

@@ -174,7 +174,7 @@ the query details.
 ## Managing Sidekiq queues
 
 It is possible to use [Sidekiq API](https://github.com/mperham/sidekiq/wiki/API)
-to perform a number of troubleshoting on Sidekiq.
+to perform a number of troubleshooting on Sidekiq.
 
 These are the administrative commands and it should only be used if currently
 admin interface is not suitable due to scale of installation.

doc/ci/chatops/README.md

@@ -61,7 +61,7 @@ ls:
 ## GitLab ChatOps Examples
 
 The GitLab.com team created a repository of [common ChatOps scripts they use to interact with our Production instance of GitLab](https://gitlab.com/gitlab-com/chatops). They are likely useful
-to other adminstrators of GitLab instances and can serve as inspiration for ChatOps scripts you can write to interact with your own applications.
+to other administrators of GitLab instances and can serve as inspiration for ChatOps scripts you can write to interact with your own applications.
 
 ## GitLab ChatOps icon
 

doc/ci/docker/using_docker_images.md

@@ -513,7 +513,7 @@ To define which should be used, the GitLab Runner process reads the configuratio
 
 NOTE: **Note:**
 GitLab Runner reads this configuration **only** from `config.toml` and ignores it if
-it's provided as an environment variable. This is because GitLab Runnner uses **only**
+it's provided as an environment variable. This is because GitLab Runner uses **only**
 `config.toml` configuration and doesn't interpolate **ANY** environment variables at
 runtime.
 

doc/ci/examples/deployment/README.md

@@ -4,7 +4,7 @@ type: tutorial
 
 # Using Dpl as deployment tool
 
-[Dpl](https://github.com/travis-ci/dpl) (prouncounced like the letters D-P-L) is a deploy tool made for
+[Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for
 continuous deployment that's developed and used by Travis CI, but can also be
 used with GitLab CI.
 

doc/ci/jenkins/index.md

@@ -26,7 +26,7 @@ There are some high level differences between the products worth mentioning:
   feature.
 - The `.gitlab-ci.yml` file is checked in to the root of your repository, much like a Jenkinsfile, but
   is in the YAML format (see [complete reference](../yaml/README.md)) instead of a Groovy DSL. It's most
-  analagous to the declarative Jenkinsfile format.
+  analogous to the declarative Jenkinsfile format.
 - GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using
   container images to set up your build environment.
 
@@ -207,7 +207,7 @@ Because GitLab is integrated tightly with Git, SCM polling options for triggers
 
 #### `tools`
 
-GitLab does not support a separate `tools` directive. Our best-practice reccomendation is to use pre-built
+GitLab does not support a separate `tools` directive. Our best-practice recommendation is to use pre-built
 container images, which can be cached, and can be built to already contain the tools you need for your pipelines. Pipelines can
 be set up to automatically build these images as needed and deploy them to the [container registry](../../user/packages/container_registry/index.md).
 

doc/ci/merge_request_pipelines/index.md

@@ -136,7 +136,7 @@ Review App set up, helping to save resources.
 
 ## Excluding certain branches
 
-Pipelines for merge requests require special treatement when
+Pipelines for merge requests require special treatment when
 using [`only`/`except`](../yaml/README.md#onlyexcept-basic). Unlike ordinary
 branch refs (for example `refs/heads/my-feature-branch`), merge request refs
 use a special Git reference that looks like `refs/merge-requests/:iid/head`. Because

doc/ci/yaml/README.md

@@ -830,7 +830,7 @@ In the example above, a pipeline could fail due to changes to a file in `service
 A later commit could then be pushed that does not include any changes to this file,
 but includes changes to the `Dockerfile`, and this pipeline could pass because it is only
 testing the changes to the `Dockerfile`. GitLab checks the **most recent pipeline**,
-that **passed**, and will show the merge request as mergable, despite the earlier
+that **passed**, and will show the merge request as mergeable, despite the earlier
 failed pipeline caused by a change that was not yet corrected.
 
 With this configuration, care must be taken to check that the most recent pipeline

doc/development/code_review.md

@@ -314,7 +314,7 @@ experience, refactors the existing code). Then:
 - Ensure the target branch is not too far behind master. If
 [master is red](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
 it should be no more than 100 commits behind.
-- Consider warnings and errors from danger bot, codequality, and other reports.
+- Consider warnings and errors from danger bot, code quality, and other reports.
 Unless a strong case can be made for the violation, these should be resolved
 before merge.
 - Ensure a passing CI pipeline or if [master is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master), post a comment mentioning the failure happens in master with a