Add latest changes from gitlab-org/gitlab@master

18 files changed, 22 insertions, 22 deletions

diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index b83814560c7..0109d87921b 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -197,19 +197,19 @@ For more fine tuning, read also about the
 
 The most common use case of cache is to preserve contents between subsequent
 runs of jobs for things like dependencies and commonly used libraries
-(Nodejs packages, PHP packages, rubygems, Python libraries, etc.),
+(Node.js packages, PHP packages, rubygems, Python libraries, etc.),
 so they don't have to be re-fetched from the public internet.
 
 NOTE: **Note:**
 For more examples, check out our [GitLab CI/CD
 templates](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/ci/templates).
 
-### Caching Nodejs dependencies
+### Caching Node.js dependencies
 
 Assuming your project is using [npm](https://www.npmjs.com/) or
-[Yarn](https://classic.yarnpkg.com/en/) to install the Nodejs dependencies, the
+[Yarn](https://classic.yarnpkg.com/en/) to install the Node.js dependencies, the
 following example defines `cache` globally so that all jobs inherit it.
-Nodejs modules are installed in `node_modules/` and are cached per-branch:
+Node.js modules are installed in `node_modules/` and are cached per-branch:
 
 ```yaml
 #
diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index c9c78c9a4e4..f780a13998c 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -6,7 +6,7 @@ type: tutorial
 
 This guide covers the building of dependencies of a PHP project while compiling assets via an NPM script using [GitLab CI/CD](../../README.md).
 
-While it is possible to create your own image with custom PHP and Node JS versions, for brevity, we will use an existing [Docker image](https://hub.docker.com/r/tetraweb/php/) that contains both PHP and NodeJS installed.
+While it is possible to create your own image with custom PHP and Node.js versions, for brevity, we will use an existing [Docker image](https://hub.docker.com/r/tetraweb/php/) that contains both PHP and Node.js installed.
 
 ```yaml
 image: tetraweb/php
@@ -23,7 +23,7 @@ before_script:
   - php -r "unlink('composer-setup.php');"
 ```
 
-This will make sure we have all requirements ready. Next, we want to run `composer install` to fetch all PHP dependencies  and `npm install` to load node packages, then run the `npm` script. We need to append them  into `before_script` section:
+This will make sure we have all requirements ready. Next, we want to run `composer install` to fetch all PHP dependencies  and `npm install` to load Node.js packages, then run the `npm` script. We need to append them  into `before_script` section:
 
 ```yaml
 before_script:
diff --git a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
index 3de8f3c675c..28d16ebb8c5 100644
--- a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
+++ b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
@@ -74,7 +74,7 @@ gitlab-runner register \
   --description "ruby:2.6" \
   --executor "docker" \
   --docker-image ruby:2.6 \
-  --docker-postgres latest
+  --docker-services latest
 ```
 
 With the command above, you create a Runner that uses the [ruby:2.6](https://hub.docker.com/_/ruby) image and uses a [postgres](https://hub.docker.com/_/postgres) database.
diff --git a/doc/ci/jenkins/index.md b/doc/ci/jenkins/index.md
index edb585c0a21..db97a6b4f2c 100644
--- a/doc/ci/jenkins/index.md
+++ b/doc/ci/jenkins/index.md
@@ -102,7 +102,7 @@ and is meant to be a mapping of concepts there to concepts in GitLab.
 
 The agent section is used to define how a pipeline will be executed. For GitLab, we use the [GitLab Runner](../runners/README.md)
 to provide this capability. You can configure your own runners in Kubernetes or on any host, or take advantage
-of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users.) The link above will bring you to the documenation which will describe how to get
+of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users.) The link above will bring you to the documentation which will describe how to get
 up and running quickly. We also support using [tags](../runners/README.md#using-tags) to direct different jobs
 to different Runners (execution agents).
 
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index ba64194472f..aa2890ed9db 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -1641,7 +1641,7 @@ cache:
     - node_modules
 ```
 
-In this example we are creating a cache for Ruby and Nodejs dependencies that
+In this example we are creating a cache for Ruby and Node.js dependencies that
 is tied to current versions of the `Gemfile.lock` and `package.json` files. Whenever one of
 these files changes, a new cache key is computed and a new cache is created. Any future
 job runs using the same `Gemfile.lock` and `package.json`  with `cache:key:files` will
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 101897ecb7c..c5ac8c040f8 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -129,7 +129,7 @@ Component statuses are linked to configuration documentation for each component.
 | [Unicorn (GitLab Rails)](#unicorn) | Handles requests for the web interface and API | [✅][unicorn-omnibus] | [✅][unicorn-charts] | [✅][unicorn-charts] | [✅](../user/gitlab_com/index.md#unicorn) | [⚙][unicorn-source] | [✅][gitlab-yml] | CE & EE |
 | [Sidekiq](#sidekiq) | Background jobs processor | [✅][sidekiq-omnibus] | [✅][sidekiq-charts] | [✅](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/index.html) | [✅](../user/gitlab_com/index.md#sidekiq) | [✅][gitlab-yml] | [✅][gitlab-yml] | CE & EE |
 | [Gitaly](#gitaly) | Git RPC service for handling all Git calls made by GitLab | [✅][gitaly-omnibus] | [✅][gitaly-charts] | [✅][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][gitaly-source] | ✅ | CE & EE |
-| [Praefect](#praefect) | A transparant proxy between any Git client and Gitaly storage nodes. | [✅][gitaly-omnibus] | [❌][gitaly-charts] | [❌][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][praefect-source] | ✅ | CE & EE |
+| [Praefect](#praefect) | A transparent proxy between any Git client and Gitaly storage nodes. | [✅][gitaly-omnibus] | [❌][gitaly-charts] | [❌][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][praefect-source] | ✅ | CE & EE |
 | [GitLab Workhorse](#gitlab-workhorse) | Smart reverse proxy, handles large HTTP requests | [✅][workhorse-omnibus] | [✅][workhorse-charts] | [✅][workhorse-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][workhorse-source] | ✅ | CE & EE |
 | [GitLab Shell](#gitlab-shell) | Handles `git` over SSH sessions | [✅][shell-omnibus] | [✅][shell-charts] | [✅][shell-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][shell-source] | [✅][gitlab-yml] | CE & EE |
 | [GitLab Pages](#gitlab-pages) | Hosts static websites | [⚙][pages-omnibus] | [❌][pages-charts] | [❌][pages-charts] | [✅](../user/gitlab_com/index.md#gitlab-pages) | [⚙][pages-source] | [⚙][pages-gdk] | CE & EE  |
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index eba650ea22f..7c2a7a6560e 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -159,7 +159,7 @@ the issue should be relabelled as ~"group::access" while keeping the original
 ~"devops::create" unchanged.
 
 We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/).
-Please read [Stage and Group labels in Throughtput](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput) for more information on how the labels are used in this context.
+Please read [Stage and Group labels in Throughput](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput) for more information on how the labels are used in this context.
 
 ### Category labels
 
diff --git a/doc/development/diffs.md b/doc/development/diffs.md
index ac0b8555360..43d0d6b4902 100644
--- a/doc/development/diffs.md
+++ b/doc/development/diffs.md
@@ -8,7 +8,7 @@ Currently we rely on different sources to present diffs, these include:
 
 ## Deep Dive
 
-In Jaunary 2019, Oswaldo Ferreira hosted a [Deep Dive] on GitLab's Diffs and Commenting on Diffs functionality to share his domain specific knowledge with anyone who may work in this part of the code base in the future. You can find the [recording on YouTube], and the slides on [Google Slides] and in [PDF]. Everything covered in this deep dive was accurate as of GitLab 11.7, and while specific details may have changed since then, it should still serve as a good introduction.
+In January 2019, Oswaldo Ferreira hosted a [Deep Dive] on GitLab's Diffs and Commenting on Diffs functionality to share his domain specific knowledge with anyone who may work in this part of the code base in the future. You can find the [recording on YouTube], and the slides on [Google Slides] and in [PDF]. Everything covered in this deep dive was accurate as of GitLab 11.7, and while specific details may have changed since then, it should still serve as a good introduction.
 
 [Deep Dive]: https://gitlab.com/gitlab-org/create-stage/issues/1
 [recording on YouTube]: https://www.youtube.com/watch?v=K6G3gMcFyek
diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index c54c2050790..469e8146447 100644
--- a/doc/development/integrations/secure.md
+++ b/doc/development/integrations/secure.md
@@ -37,7 +37,7 @@ For instance, it is common practice to use `before_script` to install system lib
 a particular project needs before performing SAST or Dependency Scanning.
 
 Similarly, [`after_script`](../../ci/yaml/README.md#before_script-and-after_script)
-should not not be used in the job definition, because it may be overriden by users.
+should not not be used in the job definition, because it may be overridden by users.
 
 ### Stage
 
diff --git a/doc/development/internal_api.md b/doc/development/internal_api.md
index 0bdc1d07591..b0c35b57422 100644
--- a/doc/development/internal_api.md
+++ b/doc/development/internal_api.md
@@ -47,7 +47,7 @@ POST /internal/allowed
 | `protocol` | string | yes     | SSH when called from GitLab-shell, HTTP or SSH when called from Gitaly |
 | `action`   | string | yes     | Git command being run (`git-upload-pack`, `git-receive-pack`, `git-upload-archive`) |
 | `changes`  | string | yes     | `<oldrev> <newrev> <refname>` when called from Gitaly, The magic string `_any` when called from GitLab Shell |
-| `check_ip` | string | no     | Ip adress from which call to GitLab Shell was made |
+| `check_ip` | string | no     | Ip address from which call to GitLab Shell was made |
 
 Example request:
 
diff --git a/doc/development/logging.md b/doc/development/logging.md
index 780038cf2dd..a90d78ba8d9 100644
--- a/doc/development/logging.md
+++ b/doc/development/logging.md
@@ -265,7 +265,7 @@ provides helper methods to track exceptions:
    and DOES NOT send the exception to Sentry,
 1. `Gitlab::ErrorTracking.track_and_raise_for_dev_exception`: this method logs,
    sends exception to Sentry (if configured) and re-raises the exception
-  for development and test enviroments.
+  for development and test environments.
 
 It is advised to only use `Gitlab::ErrorTracking.track_and_raise_exception`
 and `Gitlab::ErrorTracking.track_exception` as presented on below examples.
diff --git a/doc/development/reactive_caching.md b/doc/development/reactive_caching.md
index 3563ff5322a..bc5fbb58af9 100644
--- a/doc/development/reactive_caching.md
+++ b/doc/development/reactive_caching.md
@@ -207,7 +207,7 @@ the default by adding the following to your service:
 - `ReactiveCaching` uses `Gitlab::ExclusiveLease` to ensure that the cache calculation
 is never run concurrently by multiple workers.
 - This attribute is the timeout for the `Gitlab::ExclusiveLease`.
-- It defaults to 2 minutes, but can be overriden if a different timeout is required.
+- It defaults to 2 minutes, but can be overridden if a different timeout is required.
 
 ```ruby
 self.reactive_cache_lease_timeout = 2.minutes
diff --git a/doc/development/scalability.md b/doc/development/scalability.md
index 37ffdbdbfde..3a9f5387b11 100644
--- a/doc/development/scalability.md
+++ b/doc/development/scalability.md
@@ -178,7 +178,7 @@ talking to the primary can mitigate this.
 
 In the second case, existing connections to the newly-demoted replica
 may execute a write query, which would fail. During a failover, it may
-be advantegeous to shut down the PgBouncer talking to the primary to
+be advantageous to shut down the PgBouncer talking to the primary to
 ensure no more traffic arrives for it. The alternative would be to make
 the application aware of the failover event and terminate its
 connections gracefully.
diff --git a/doc/development/testing_guide/end_to_end/best_practices.md b/doc/development/testing_guide/end_to_end/best_practices.md
index e060312e05f..97daf4885ca 100644
--- a/doc/development/testing_guide/end_to_end/best_practices.md
+++ b/doc/development/testing_guide/end_to_end/best_practices.md
@@ -78,7 +78,7 @@ That's not possible if a test leaves the browser logged in when it finishes. Nor
 
 For an example see: <https://gitlab.com/gitlab-org/gitlab/issues/34736>
 
-Ideally, any actions peformed in an `after(:context)` (or [`before(:context)`](#limit-the-use-of-beforeall-and-after-hooks)) block would be performed via the API. But if it's necessary to do so via the UI (e.g., if API functionality doesn't exist), make sure to log out at the end of the block.
+Ideally, any actions performed in an `after(:context)` (or [`before(:context)`](#limit-the-use-of-beforeall-and-after-hooks)) block would be performed via the API. But if it's necessary to do so via the UI (e.g., if API functionality doesn't exist), make sure to log out at the end of the block.
 
 ```ruby
 after(:all) do
diff --git a/doc/development/value_stream_analytics.md b/doc/development/value_stream_analytics.md
index 5c6d3f18d9a..3ceb523ab73 100644
--- a/doc/development/value_stream_analytics.md
+++ b/doc/development/value_stream_analytics.md
@@ -235,7 +235,7 @@ SELECT (START_EVENT_TIME-END_EVENT_TIME) as duration, END_EVENT.timestamp
 - Services (`Analytics::CycleAnalytics` module): All `Stage` related actions will be delegated to respective service objects.
 - Models (`Analytics::CycleAnalytics` module): Models are used to persist the `Stage` objects `ProjectStage` and `GroupStage`.
 - Feature classes (`Gitlab::Analytics::CycleAnalytics` module):
-  - Responsible for composing queries and define feature specific busines logic.
+  - Responsible for composing queries and define feature specific business logic.
   - `DataCollector`, `Event`, `StageEvents`, etc.
 
 ## Testing
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index ad203b2a7cf..abd946e1f23 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -805,7 +805,7 @@ commands to be wrapped as follows:
 /bin/herokuish procfile exec $COMMAND
 ```
 
-This might be neccessary, for example, when:
+This might be necessary, for example, when:
 
 - Attaching using `kubectl exec`.
 - Using GitLab's [Web Terminal](../../ci/environments.md#web-terminals).
diff --git a/doc/topics/web_application_firewall/index.md b/doc/topics/web_application_firewall/index.md
index db1265e08ac..6c847f12bba 100644
--- a/doc/topics/web_application_firewall/index.md
+++ b/doc/topics/web_application_firewall/index.md
@@ -55,7 +55,7 @@ you can configure a cluster on GKE. Once this is set up, you can follow the step
 
 NOTE: **Note**
 This guide shows how the WAF can be deployed using Auto DevOps. The WAF
-is avaliable by default to all applications no matter how they are deployed,
+is available by default to all applications no matter how they are deployed,
 as long as they are using Ingress.
 
 ## Network firewall vs. Web Application Firewall
diff --git a/doc/topics/web_application_firewall/quick_start_guide.md b/doc/topics/web_application_firewall/quick_start_guide.md
index 35003785753..e3cf0bcd498 100644
--- a/doc/topics/web_application_firewall/quick_start_guide.md
+++ b/doc/topics/web_application_firewall/quick_start_guide.md
@@ -12,7 +12,7 @@ need to ensure your own [Runners are configured](../../ci/runners/README.md) and
 [Google OAuth is enabled](../../integration/google.md).
 
 **Note**: GitLab's Web Application Firewall is deployed with [Ingress](../../user/clusters/applications.md#Ingress),
-so it will be avaliable to your applications no matter how you deploy them to Kubernetes.
+so it will be available to your applications no matter how you deploy them to Kubernetes.
 
 ## Enable or disable ModSecurity