Add latest changes from gitlab-org/gitlab@master

9 files changed, 15 insertions, 15 deletions

diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 61e42ecfe83..a9d8941488f 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -208,7 +208,7 @@ available online on 2018-09-15, but, as the feature freeze date has passed, if
 the MR does not have a "pick into 11.3" label, the milestone has to be changed
 to 11.4 and it will be shipped with all GitLab packages only on 2018-10-22,
 with GitLab 11.4. Meaning, it will only be available under `/help` from GitLab
-11.4 onwards, but available on <https://docs.gitlab.com/> on the same day it was merged.
+11.4 onward, but available on <https://docs.gitlab.com/> on the same day it was merged.
 
 ### Linking to `/help`
 
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index ec50b1557d4..6552ed29e98 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -93,7 +93,7 @@ the following:
 The query plan can answer the questions whether we need additional
 indexes, or whether we perform expensive filtering (i.e. using sequential scans).
 
-Each query plan should be run against substantional size of data set.
+Each query plan should be run against substantial size of data set.
 For example if you look for issues with specific conditions,
 you should consider validating the query against
 a small number (a few hundred) and a big number (100_000) of issues.
@@ -318,7 +318,7 @@ Take into consideration the following when choosing a pagination strategy:
 
 1. It is very inefficient to calculate amount of objects that pass the filtering,
    this operation usually can take seconds, and can time out,
-1. It is very inefficent to get entries for page at higher ordinals, like 1000.
+1. It is very inefficient to get entries for page at higher ordinals, like 1000.
    The database has to sort and iterate all previous items, and this operation usually
    can result in substantial load put on database.
 
@@ -363,7 +363,7 @@ The intent of quotas could be different:
 
 1. We want to provide higher quotas for higher tiers of features:
    we want to provide on GitLab.com more capabilities for different tiers,
-1. We want to prevent misuse of the feature: someone accidentially creates
+1. We want to prevent misuse of the feature: someone accidentally creates
    10000 deploy tokens, because of a broken API script,
 1. We want to prevent abuse of the feature: someone purposely creates
    a 10000 pipelines to take advantage of the system.
@@ -374,7 +374,7 @@ Examples:
    more than 50 schedules.
    In such cases it is rather expected that this is either misuse
    or abuse of the feature. Lack of the upper limit can result
-   in service degredation as the system will try to process all schedules
+   in service degradation as the system will try to process all schedules
    assigned the the project.
 
 1. GitLab CI includes: We started with the limit of maximum of 50 nested includes.
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 6301ba778bc..cccea4ee9f4 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -323,7 +323,7 @@ In this particular case, the default value exists and we're just changing the me
 in the `namespaces` table. Only when creating a new column with a default, all the records are going be rewritten.
 
 NOTE: **Note:**  A faster [ALTER TABLE ADD COLUMN with a non-null default](https://www.depesz.com/2018/04/04/waiting-for-postgresql-11-fast-alter-table-add-column-with-a-non-null-default/)
-was introduced on PostgresSQL 11.0, removing the need of rewritting the table when a new column with a default value is added.
+was introduced on PostgresSQL 11.0, removing the need of rewriting the table when a new column with a default value is added.
 
 For the reasons mentioned above, it's safe to use `change_column_default` in a single-transaction migration
 without requiring `disable_ddl_transaction!`.
diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md
index ba50b013c9f..7da74ae8b35 100644
--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@@ -132,11 +132,11 @@ for the list of exact patterns.**
 ## Rules conditions and changes patterns
 
 We're making use of the [`rules` keyword](https://docs.gitlab.com/ee/ci/yaml/#rules) but we're currently
-duplicating the `if` conditions and `changes` patterns lists since they cannot be shared accross
+duplicating the `if` conditions and `changes` patterns lists since they cannot be shared across
 `include`d files as we do with `extends`.
 
 **If you update an `if` condition or `changes`
-patterns list, make sure to mass-update those accross all the CI config files (i.e. `.gitlab/ci/*.yml`).**
+patterns list, make sure to mass-update those across all the CI config files (i.e. `.gitlab/ci/*.yml`).**
 
 ### Canonical commits only
 
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 8dd5e2b1265..a845b5a26e8 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -67,7 +67,7 @@ When using spring and guard together, use `SPRING=1 bundle exec guard` instead t
 - Don't supply the `:each` argument to hooks since it's the default.
 - On `before` and `after` hooks, prefer it scoped to `:context` over `:all`
 - When using `evaluate_script("$('.js-foo').testSomething()")` (or `execute_script`) which acts on a given element,
-  use a Capyabara matcher beforehand (e.g. `find('.js-foo')`) to ensure the element actually exists.
+  use a Capybara matcher beforehand (e.g. `find('.js-foo')`) to ensure the element actually exists.
 - Use `focus: true` to isolate parts of the specs you want to run.
 - Use [`:aggregate_failures`](https://relishapp.com/rspec/rspec-core/docs/expectation-framework-integration/aggregating-failures) when there is more than one expectation in a test.
 - For [empty test description blocks](https://github.com/rubocop-hq/rspec-style-guide#it-and-specify), use `specify` rather than `it do` if the test is self-explanatory.
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 fc00fcea67e..e060312e05f 100644
--- a/doc/development/testing_guide/end_to_end/best_practices.md
+++ b/doc/development/testing_guide/end_to_end/best_practices.md
@@ -14,7 +14,7 @@ Now, realize that almost all tests need the user to be logged in, and that we ne
 
 Now, multiply the number of tests per 2 seconds, and as your test suite grows, the time to run it grows with it, and this is not sustainable.
 
-An alternative to perform a login in a cheaper way would be having an endpoint (available only for testing) where we could pass the user's credentials as encrypted values as query strings, and then we would be redirected to the logged in home page if the credentials are valid. Let's say that, on average, this process takes only 200 miliseconds.
+An alternative to perform a login in a cheaper way would be having an endpoint (available only for testing) where we could pass the user's credentials as encrypted values as query strings, and then we would be redirected to the logged in home page if the credentials are valid. Let's say that, on average, this process takes only 200 milliseconds.
 
 You see the point right?
 
diff --git a/doc/development/testing_guide/end_to_end/quick_start_guide.md b/doc/development/testing_guide/end_to_end/quick_start_guide.md
index fb820ac22a2..be00129a2bc 100644
--- a/doc/development/testing_guide/end_to_end/quick_start_guide.md
+++ b/doc/development/testing_guide/end_to_end/quick_start_guide.md
@@ -445,7 +445,7 @@ end
 
 By defining the `resource_web_url(resource)` method, we override the one from the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/resource/api_fabricator.rb#L44) module. We do that to avoid failing the test due to this particular resource not exposing a `web_url` property.
 
-By defining the `api_get_path` method, we **would** allow for the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to get a single label, but since there's no path available for that in the publich API, we raise a `NotImplementedError` instead.
+By defining the `api_get_path` method, we **would** allow for the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to get a single label, but since there's no path available for that in the public API, we raise a `NotImplementedError` instead.
 
 By defining the `api_post_path` method, we allow for the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to create a new label in a specific project.
 
diff --git a/doc/development/testing_guide/flaky_tests.md b/doc/development/testing_guide/flaky_tests.md
index 708003f2569..5628ca633f6 100644
--- a/doc/development/testing_guide/flaky_tests.md
+++ b/doc/development/testing_guide/flaky_tests.md
@@ -76,7 +76,7 @@ This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/m
 
 ### Feature tests
 
-- [Be sure to create all the data the test need before starting exercize](https://gitlab.com/gitlab-org/gitlab-foss/issues/32622#note_31128195): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12059>
+- [Be sure to create all the data the test need before starting exercise](https://gitlab.com/gitlab-org/gitlab-foss/issues/32622#note_31128195): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12059>
 - [Bis](https://gitlab.com/gitlab-org/gitlab-foss/issues/34609#note_34048715): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12604>
 - [Bis](https://gitlab.com/gitlab-org/gitlab-foss/issues/34698#note_34276286): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12664>
 - [Assert against the underlying database state instead of against a page's content](https://gitlab.com/gitlab-org/gitlab-foss/issues/31437): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10934>
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index 8934f0d4b65..56b059063e0 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -315,7 +315,7 @@ export, one is be generated by the babel plugin). The second parameter is the
 name of the import you wish to change. The result of the function is a Spy
 object which can be treated like any other Jasmine spy object.
 
-Further documentation on the babel rewire pluign API can be found on
+Further documentation on the babel rewire plugin API can be found on
 [its repository Readme doc](https://github.com/speedskater/babel-plugin-rewire#babel-plugin-rewire).
 
 #### Waiting in tests
@@ -532,7 +532,7 @@ In order to ensure that a clean wrapper object and DOM are being used in each te
   });
 ```
 
-See also the [Vue Test Utils documention on `destroy`](https://vue-test-utils.vuejs.org/api/wrapper/#destroy).
+See also the [Vue Test Utils documentation on `destroy`](https://vue-test-utils.vuejs.org/api/wrapper/#destroy).
 
 #### Migrating flaky Karma tests to Jest
 
@@ -649,7 +649,7 @@ it('uses some HTML element', () => {
 HTML and JSON fixtures are generated from backend views and controllers using RSpec (see `spec/frontend/fixtures/*.rb`).
 
 For each fixture, the content of the `response` variable is stored in the output file.
-This variable gets automagically set if the test is marked as `type: :request` or `type: :controller`.
+This variable gets automatically set if the test is marked as `type: :request` or `type: :controller`.
 Fixtures are regenerated using the `bin/rake frontend:fixtures` command but you can also generate them individually,
 for example `bin/rspec spec/frontend/fixtures/merge_requests.rb`.
 When creating a new fixture, it often makes sense to take a look at the corresponding tests for the endpoint in `(ee/)spec/controllers/` or `(ee/)spec/requests/`.