Add latest changes from gitlab-org/gitlab@master

10 files changed, 10 insertions, 10 deletions

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