Add latest changes from gitlab-org/gitlab@master

19 files changed, 33 insertions, 33 deletions

diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md
index 6932858c699..3ddb15fa290 100644
--- a/doc/development/adding_database_indexes.md
+++ b/doc/development/adding_database_indexes.md
@@ -105,7 +105,7 @@ ORDER BY pg_relation_size(indexrelname::regclass) desc;
 ```
 
 This query outputs a list containing all indexes that are never used and sorts
-them by indexes sizes in descending order.  This query can be useful to
+them by indexes sizes in descending order. This query can be useful to
 determine if any previously indexes are useful after all. More information on
 the meaning of the various columns can be found at
 <https://www.postgresql.org/docs/current/monitoring-stats.html>.
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index ddece96a9af..41ebcc7f2d0 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -107,7 +107,7 @@ confidence in their solution will not have been reached.
 
 Before the review, the author is requested to submit comments on the merge
 request diff alerting the reviewer to anything important as well as for anything
-that demands further explanation or attention.  Examples of content that may
+that demands further explanation or attention. Examples of content that may
 warrant a comment could be:
 
 - The addition of a linting rule (Rubocop, JS etc)
@@ -181,8 +181,8 @@ vulnerabilities must be either empty or containing:
 Maintainers should **never** dismiss vulnerabilities to "empty" the list,
 without duly verifying them.
 
-Note that certain Merge Requests may target a stable branch.  These are rare
-events.  These types of Merge Requests cannot be merged by the Maintainer.
+Note that certain Merge Requests may target a stable branch. These are rare
+events. These types of Merge Requests cannot be merged by the Maintainer.
 Instead these should be sent to the [Release Manager](https://about.gitlab.com/community/release-managers/).
 
 ## Best practices
diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 233bf255361..8270e52e0ab 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -82,9 +82,9 @@ When you submit code to GitLab, we really want it to get merged, but there will
 
 When maintainers are reading through a merge request they may request guidance from other maintainers. If merge request maintainers conclude that the code should not be merged, our reasons will be fully disclosed. If it has been decided that the code quality is not up to GitLab’s standards, the merge request maintainer will refer the author to our docs and code style guides, and provide some guidance.
 
-Sometimes style guides will be followed but the code will lack structural integrity, or the maintainer will have reservations about the code’s overall quality. When there is a reservation the maintainer will inform the author and provide some guidance.  The author may then choose to update the merge request. Once the merge request has been updated and reassigned to the maintainer, they will review the code again. Once the code has been resubmitted any number of times, the maintainer may choose to close the merge request with a summary of why it will not be merged, as well as some guidance. If the merge request is closed the maintainer will be open to discussion as to how to improve the code so it can be approved in the future.
+Sometimes style guides will be followed but the code will lack structural integrity, or the maintainer will have reservations about the code’s overall quality. When there is a reservation the maintainer will inform the author and provide some guidance. The author may then choose to update the merge request. Once the merge request has been updated and reassigned to the maintainer, they will review the code again. Once the code has been resubmitted any number of times, the maintainer may choose to close the merge request with a summary of why it will not be merged, as well as some guidance. If the merge request is closed the maintainer will be open to discussion as to how to improve the code so it can be approved in the future.
 
-GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/company/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request.  For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches.
+GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/company/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request. For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches.
 
 GitLab receives a lot of community contributions, so if your code has not been reviewed within two days (excluding weekend and public holidays) of its initial submission feel free to re-mention the appropriate merge request coach.
 
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md
index e3ec69b6489..b8d2a873d8b 100644
--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
@@ -193,7 +193,7 @@ You might get an error such as
 
 This is because you've exceeded the disk space threshold - it thinks you don't have enough disk space left, based on the default 95% threshold.
 
-In addition, the `read_only_allow_delete` setting will be set to `true`.  It will block indexing, `forcemerge`, etc
+In addition, the `read_only_allow_delete` setting will be set to `true`. It will block indexing, `forcemerge`, etc
 
 ```
 curl "http://localhost:9200/gitlab-development/_settings?pretty"
diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md
index 6d5021c0f08..fcba8758c2f 100644
--- a/doc/development/fe_guide/performance.md
+++ b/doc/development/fe_guide/performance.md
@@ -85,15 +85,15 @@ browser's developer console while on any page within GitLab.
 #### Important Considerations
 
 - **Keep Entry Points Lite:**
-  Page-specific JavaScript entry points should be as lite as possible.  These
+  Page-specific JavaScript entry points should be as lite as possible. These
   files are exempt from unit tests, and should be used primarily for
   instantiation and dependency injection of classes and methods that live in
-  modules outside of the entry point script.  Just import, read the DOM,
+  modules outside of the entry point script. Just import, read the DOM,
   instantiate, and nothing else.
 
 - **Entry Points May Be Asynchronous:**
   _DO NOT ASSUME_ that the DOM has been fully loaded and available when an
-  entry point script is run.  If you require that some code be run after the
+  entry point script is run. If you require that some code be run after the
   DOM has loaded, you should attach an event handler to the `DOMContentLoaded`
   event with:
 
@@ -113,7 +113,7 @@ browser's developer console while on any page within GitLab.
     with a relative path (e.g. `import initMyWidget from './my_widget';`).
   - If a class or module is _used by multiple routes_, place it within a
     shared directory at the closest common parent directory for the entry
-    points that import it.  For example, if `my_widget.js` is imported within
+    points that import it. For example, if `my_widget.js` is imported within
     both `pages/widget/show/index.js` and `pages/widget/run/index.js`, then
     place the module at `pages/widget/shared/my_widget.js` and import it with
     a relative path if possible (e.g. `../shared/my_widget`).
@@ -122,7 +122,7 @@ browser's developer console while on any page within GitLab.
   For GitLab Enterprise Edition, page-specific entry points will override their
   Community Edition counterparts with the same name, so if
   `ee/app/assets/javascripts/pages/foo/bar/index.js` exists, it will take
-  precedence over `app/assets/javascripts/pages/foo/bar/index.js`.  If you want
+  precedence over `app/assets/javascripts/pages/foo/bar/index.js`. If you want
   to minimize duplicate code, you can import one entry point from the other.
   This is not done automatically to allow for flexibility in overriding
   functionality.
@@ -131,7 +131,7 @@ browser's developer console while on any page within GitLab.
 
 For any code that does not need to be run immediately upon page load, (e.g.
 modals, dropdowns, and other behaviors that can be lazy-loaded), you can split
-your module into asynchronous chunks with dynamic import statements.  These
+your module into asynchronous chunks with dynamic import statements. These
 imports return a Promise which will be resolved once the script has loaded:
 
 ```javascript
diff --git a/doc/development/github_importer.md b/doc/development/github_importer.md
index 5445f36b9fa..6b8c083d55f 100644
--- a/doc/development/github_importer.md
+++ b/doc/development/github_importer.md
@@ -140,7 +140,7 @@ long we're still performing work.
 GitHub has a rate limit of 5 000 API calls per hour. The number of requests
 necessary to import a project is largely dominated by the number of unique users
 involved in a project (e.g. issue authors). Other data such as issue pages
-and comments typically only requires a few dozen requests to import.  This is
+and comments typically only requires a few dozen requests to import. This is
 because we need the Email address of users in order to map them to GitLab users.
 
 We handle this by doing the following:
diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md
index 71c5be7c0cf..1be09bfeddf 100644
--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@@ -188,9 +188,9 @@ code readability and test output.
 ### Better output in tests
 
 When comparing expected and actual values in tests, use
-[testify/require.Equal](https://godoc.org/github.com/stretchr/testify/require#Equal),
-[testify/require.EqualError](https://godoc.org/github.com/stretchr/testify/require#EqualError),
-[testify/require.EqualValues](https://godoc.org/github.com/stretchr/testify/require#EqualValues),
+[`testify/require.Equal`](https://godoc.org/github.com/stretchr/testify/require#Equal),
+[`testify/require.EqualError`](https://godoc.org/github.com/stretchr/testify/require#EqualError),
+[`testify/require.EqualValues`](https://godoc.org/github.com/stretchr/testify/require#EqualValues),
 and others to improve readability when comparing structs, errors,
 large portions of text, or JSON documents:
 
diff --git a/doc/development/logging.md b/doc/development/logging.md
index b649f6a9b05..780038cf2dd 100644
--- a/doc/development/logging.md
+++ b/doc/development/logging.md
@@ -129,7 +129,7 @@ importer progresses. Here's what to do:
 
 ## Multi-destination Logging
 
-GitLab is transitioning from unstructured/plaintext logs to structured/JSON logs.  During this transition period some logs will be recorded in multiple formats through multi-destination logging.
+GitLab is transitioning from unstructured/plaintext logs to structured/JSON logs. During this transition period some logs will be recorded in multiple formats through multi-destination logging.
 
 ### How to use multi-destination logging
 
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 18afeeb1814..2c9ad8c00cf 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -267,7 +267,7 @@ end
 
 Here the call to `disable_statement_timeout` will use the connection local to
 the `with_multiple_threads` block, instead of re-using the global connection
-pool.  This ensures each thread has its own connection object, and won't time
+pool. This ensures each thread has its own connection object, and won't time
 out when trying to obtain one.
 
 **NOTE:** PostgreSQL has a maximum amount of connections that it allows. This
diff --git a/doc/development/namespaces_storage_statistics.md b/doc/development/namespaces_storage_statistics.md
index 6ec37e830c6..71c9a0b96fb 100644
--- a/doc/development/namespaces_storage_statistics.md
+++ b/doc/development/namespaces_storage_statistics.md
@@ -26,7 +26,7 @@ by [`Namespaces#with_statistics`](https://gitlab.com/gitlab-org/gitlab/blob/4ab5
 Additionally, the pattern that is currently used to update the project statistics
 (the callback) doesn't scale adequately. It is currently one of the largest
 [database queries transactions on production](https://gitlab.com/gitlab-org/gitlab-foss/issues/62488)
-that takes the most time overall.  We can't add one more query to it as
+that takes the most time overall. We can't add one more query to it as
 it will increase the transaction's length.
 
 Because of all of the above, we can't apply the same pattern to store
diff --git a/doc/development/pry_debugging.md b/doc/development/pry_debugging.md
index 17d8428b0c0..0558a0a515a 100644
--- a/doc/development/pry_debugging.md
+++ b/doc/development/pry_debugging.md
@@ -103,7 +103,7 @@ You also can move around in the callstack with these commands:
 ## Short commands
 
 When you use `binding.pry` instead of `byebug`, the short commands
-like `s`, `n`, `f`, and `c` do not work.  To reinstall them, add this
+like `s`, `n`, `f`, and `c` do not work. To reinstall them, add this
 to `~/.pryrc`:
 
 ```ruby
diff --git a/doc/development/reactive_caching.md b/doc/development/reactive_caching.md
index 94058a3c09c..3563ff5322a 100644
--- a/doc/development/reactive_caching.md
+++ b/doc/development/reactive_caching.md
@@ -3,7 +3,7 @@
 > This doc refers to <https://gitlab.com/gitlab-org/gitlab/blob/master/app/models/concerns/reactive_caching.rb>.
 
 The `ReactiveCaching` concern is used for fetching some data in the background and store it
-in the Rails cache, keeping it up-to-date for as long as it is being requested.  If the
+in the Rails cache, keeping it up-to-date for as long as it is being requested. If the
 data hasn't been requested for `reactive_cache_lifetime`, it will stop being refreshed,
 and then be removed.
 
diff --git a/doc/development/renaming_features.md b/doc/development/renaming_features.md
index ca204bd420e..6a196921a5d 100644
--- a/doc/development/renaming_features.md
+++ b/doc/development/renaming_features.md
@@ -21,4 +21,4 @@ The more of the following that are true, the more likely you should choose the f
 
 ## Consider a façade-first approach
 
-The façade approach is not necessarily a final step.  It can (and possibly *should*) be treated as the first step, where later iterations will accomplish the complete rename.
+The façade approach is not necessarily a final step. It can (and possibly *should*) be treated as the first step, where later iterations will accomplish the complete rename.
diff --git a/doc/development/scalability.md b/doc/development/scalability.md
index d4772bf3ea5..37ffdbdbfde 100644
--- a/doc/development/scalability.md
+++ b/doc/development/scalability.md
@@ -165,7 +165,7 @@ and secondaries are set up a bit differently:
 For replicas, colocating is advantageous because it reduces network hops
 and hence latency. However, for the primary, colocating is
 disadvantageous because PgBouncer would become a single point of failure
-and cause errors.  When a failover occurs, one of two things could
+and cause errors. When a failover occurs, one of two things could
 happen:
 
 - The primary disappears from the network.
@@ -212,7 +212,7 @@ Redis process.
 #### High availability/Risks
 
 Single-core: Like PgBouncer, a single Redis process can only use one
-core.  It does not support multi-threading.
+core. It does not support multi-threading.
 
 Dumb secondaries: Redis secondaries (aka slaves) don't actually
 handle any load. Unlike PostgreSQL secondaries, they don't even serve
diff --git a/doc/development/shell_commands.md b/doc/development/shell_commands.md
index 7079f7a9914..b8952cae33e 100644
--- a/doc/development/shell_commands.md
+++ b/doc/development/shell_commands.md
@@ -126,7 +126,7 @@ Note that unlike `Gitlab::Popen.popen`, `IO.popen` does not capture standard err
 ## Avoid user input at the start of path strings
 
 Various methods for opening and reading files in Ruby can be used to read the
-standard output of a process instead of a file.  The following two commands do
+standard output of a process instead of a file. The following two commands do
 roughly the same:
 
 ```ruby
@@ -138,7 +138,7 @@ The key is to open a 'file' whose name starts with a `|`.
 Affected methods include Kernel#open, File::read, File::open, IO::open and IO::read.
 
 You can protect against this behavior of 'open' and 'read' by ensuring that an
-attacker cannot control the start of the filename string you are opening.  For
+attacker cannot control the start of the filename string you are opening. For
 instance, the following is sufficient to protect against accidentally starting
 a shell command with `|`:
 
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 3285aaed095..e3355e15455 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -536,7 +536,7 @@ reset before each example, add the `:prometheus` tag to the Rspec test.
 ### Matchers
 
 Custom matchers should be created to clarify the intent and/or hide the
-complexity of RSpec expectations.They should be placed under
+complexity of RSpec expectations. They should be placed under
 `spec/support/matchers/`. Matchers can be placed in subfolder if they apply to
 a certain type of specs only (e.g. features, requests etc.) but shouldn't be if
 they apply to multiple type of specs.
diff --git a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
index aec0a3ede5a..32b1c304a9a 100644
--- a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
+++ b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
@@ -27,7 +27,7 @@ Runtime::Browser.visit(:gitlab, Some::Page)
 
 ### Clicks
 
-When we perform a click within our tests, we expect something to occur.  That something could be a component to now
+When we perform a click within our tests, we expect something to occur. That something could be a component to now
 appear on the webpage, or the test to navigate away from the page entirely.
 
 Dynamic element validation is instituted when using
@@ -57,7 +57,7 @@ Simply put, a required element is a visible HTML element that appears on a UI co
 
 #### Application
 
-Requiring elements is very easy.  By adding `required: true` as a parameter to an `element`, you've now made it
+Requiring elements is very easy. By adding `required: true` as a parameter to an `element`, you've now made it
 a requirement that the element appear on the page upon navigation.
 
 ## Examples
diff --git a/doc/development/testing_guide/end_to_end/page_objects.md b/doc/development/testing_guide/end_to_end/page_objects.md
index f1e0de0c792..22e7375be1f 100644
--- a/doc/development/testing_guide/end_to_end/page_objects.md
+++ b/doc/development/testing_guide/end_to_end/page_objects.md
@@ -152,7 +152,7 @@ Things to note:
 - The name of the element and the qa_selector must match and be snake_cased
 - If the element appears on the page unconditionally, add `required: true` to the element. See
   [Dynamic element validation](dynamic_element_validation.md)
-- You may see `.qa-selector` classes in existing Page Objects.  We should prefer the [`data-qa-selector`](#data-qa-selector-vs-qa-selector)
+- You may see `.qa-selector` classes in existing Page Objects. We should prefer the [`data-qa-selector`](#data-qa-selector-vs-qa-selector)
   method of definition over the `.qa-selector` CSS class
 
 ### `data-qa-selector` vs `.qa-selector`
@@ -173,7 +173,7 @@ and we should prefer the `data-qa-selector` method of definition.
 
 A common occurrence in automated testing is selecting a single "one-of-many" element.
 In a list of several items, how do you differentiate what you are selecting on?
-The most common workaround for this is via text matching.  Instead, a better practice is
+The most common workaround for this is via text matching. Instead, a better practice is
 by matching on that specific element by a unique identifier, rather than by text.
 
 We got around this by adding the `data-qa-*` extensible selection mechanism.
diff --git a/doc/development/testing_guide/testing_migrations_guide.md b/doc/development/testing_guide/testing_migrations_guide.md
index 3fef13afa9c..392911b1fda 100644
--- a/doc/development/testing_guide/testing_migrations_guide.md
+++ b/doc/development/testing_guide/testing_migrations_guide.md
@@ -59,7 +59,7 @@ project = table(:projects).create!(id: 1, name: 'gitlab1', path: 'gitlab1')
 
 #### `migrate!`
 
-Use the `migrate!` helper to run the migration that is under test.  It will not only
+Use the `migrate!` helper to run the migration that is under test. It will not only
 run the migration, but will also bump the schema version in the `schema_migrations`
 table. It is necessary because in the `after` hook we trigger the rest of
 the migrations, and we need to know where to start. Example: