Add latest changes from gitlab-org/gitlab@master

12 files changed, 22 insertions, 18 deletions

diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index 6d224db1a02..ea58b71a804 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -4,7 +4,7 @@ This document outlines the styleguide for GitLab's [GraphQL API](../api/graphql/
 
 ## How GitLab implements GraphQL
 
-We use the [graphql-ruby gem](https://graphql-ruby.org/) written by [Robert Mosolgo](https://github.com/rmosolgo/).
+We use the [GraphQL Ruby gem](https://graphql-ruby.org/) written by [Robert Mosolgo](https://github.com/rmosolgo/).
 
 All GraphQL queries are directed to a single endpoint
 ([`app/controllers/graphql_controller.rb#execute`](https://gitlab.com/gitlab-org/gitlab/blob/master/app%2Fcontrollers%2Fgraphql_controller.rb)),
@@ -84,7 +84,7 @@ the context.
 
 ### Nullable fields
 
-GraphQL allows fields to be be "nullable" or "non-nullable". The former means
+GraphQL allows fields to be "nullable" or "non-nullable". The former means
 that `null` may be returned instead of a value of the specified type. **In
 general**, you should prefer using nullable fields to non-nullable ones, for
 the following reasons:
@@ -865,7 +865,7 @@ the analyzer, and the final value is also available to you.
 
 [Multiplex queries](https://graphql-ruby.org/queries/multiplex.html) enable
 multiple queries to be sent in a single request. This reduces the number of requests sent to the server.
-(there are custom Multiplex Query Analyzers and Multiplex Instrumentation provided by graphql-ruby).
+(there are custom Multiplex Query Analyzers and Multiplex Instrumentation provided by GraphQL Ruby).
 
 ### Query limits
 
@@ -888,7 +888,7 @@ end
 ```
 
 More about complexity:
-[graphql-ruby docs](https://graphql-ruby.org/queries/complexity_and_depth.html)
+[GraphQL Ruby documentation](https://graphql-ruby.org/queries/complexity_and_depth.html).
 
 ## Documentation and Schema
 
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index b5caa1d223d..436cb43199e 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -775,7 +775,7 @@ When referring to `~git` in the pictures it means the home directory of the Git
 
 GitLab is primarily installed within the `/home/git` user home directory as `git` user. Within the home directory is where the gitlabhq server software resides as well as the repositories (though the repository location is configurable).
 
-The bare repositories are located in `/home/git/repositories`. GitLab is a ruby on rails application so the particulars of the inner workings can be learned by studying how a ruby on rails application works.
+The bare repositories are located in `/home/git/repositories`. GitLab is a Ruby on rails application so the particulars of the inner workings can be learned by studying how a Ruby on rails application works.
 
 To serve repositories over SSH there's an add-on application called GitLab Shell which is installed in `/home/git/gitlab-shell`.
 
@@ -794,7 +794,7 @@ GitLab has several components to operate. It requires a persistent database
 Unicorn. All these components should run as different system users to GitLab
 (e.g., `postgres`, `redis` and `www-data`, instead of `git`).
 
-As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server
+As the `git` user it starts Sidekiq and Unicorn (a simple Ruby HTTP server
 running on port `8080` by default). Under the GitLab user there are normally 4
 processes: `unicorn_rails master` (1 process), `unicorn_rails worker`
 (2 processes), `sidekiq` (1 process).
diff --git a/doc/development/documentation/workflow.md b/doc/development/documentation/workflow.md
index aaf0f218387..01f528dcfa4 100644
--- a/doc/development/documentation/workflow.md
+++ b/doc/development/documentation/workflow.md
@@ -422,7 +422,7 @@ Request help from the Technical Writing team if you:
 
 To request help:
 
-1. Locate the the Technical Writer for the relevant
+1. Locate the Technical Writer for the relevant
    [DevOps stage group](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments).
 1. Either:
    - If urgent help is required, directly assign the Technical Writer in the issue or in the merge request.
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index 21d6d48d446..fa9942e8d81 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -98,7 +98,8 @@ Slack:
 
 This will enable the feature for GitLab.com, with `new_navigation_bar` being the
 name of the feature.
-This command does *not* enable the feature for 25% of the total users. Instead, when the feature is checked with `enabled?`, it will return `true` 25% of the time.
+This command does *not* enable the feature for 25% of the total users.
+Instead, when the feature is checked with `enabled?`, it will return `true` 25% of the time.
 
 If you are not certain what percentages to use, simply use the following steps:
 
diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md
index b8b33de8083..43e4d4d0e72 100644
--- a/doc/development/gitaly.md
+++ b/doc/development/gitaly.md
@@ -58,7 +58,7 @@ of Gitaly and `gitaly-proto` during testing and development.
 - See [below](#running-tests-with-a-locally-modified-version-of-gitaly) for instructions on running GitLab CE tests with a modified version of Gitaly.
 - In GDK run `gdk install` and restart `gdk run` (or `gdk run app`) to use a locally modified Gitaly version for development
 
-### Gitaly-ruby
+### `gitaly-ruby`
 
 It is possible to implement and test RPC's in Gitaly using Ruby code,
 in
diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index 30d6c2ae754..69128cfb625 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 overridden by users.
+should not be used in the job definition, because it may be overridden by users.
 
 ### Stage
 
@@ -403,7 +403,7 @@ It may also have an `end_line`, a `class`, and a `method`.
 
 For instance, here is the `location` object for a security flaw found
 at line `41` of `src/main/java/com/gitlab/example/App.java`,
-in the the `generateSecretToken` method of the `com.gitlab.security_products.tests.App` Java class:
+in the `generateSecretToken` method of the `com.gitlab.security_products.tests.App` Java class:
 
 ```json
 {
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index a285d30d7a5..4a9b5d26aef 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -375,7 +375,7 @@ Examples:
    In such cases it's rather expected that this is either misuse
    or abuse of the feature. Lack of the upper limit can result
    in service degradation as the system will try to process all schedules
-   assigned the the project.
+   assigned the project.
 
 1. GitLab CI/CD includes: We started with the limit of maximum of 50 nested includes.
    We understood that performance of the feature was acceptable at that level.
diff --git a/doc/development/new_fe_guide/tips.md b/doc/development/new_fe_guide/tips.md
index 2e2f5e8f47d..13222e0cc9b 100644
--- a/doc/development/new_fe_guide/tips.md
+++ b/doc/development/new_fe_guide/tips.md
@@ -16,7 +16,7 @@ Your feature flag can now be:
 
 - [Made available to the frontend](../feature_flags/development.md#frontend) via the `gon`
 - Queried in [tests](../feature_flags/development.md#specs)
-- Queried in HAML templates and ruby files via the `Feature.enabled?(:my_shiny_new_feature_flag)` method
+- Queried in HAML templates and Ruby files via the `Feature.enabled?(:my_shiny_new_feature_flag)` method
 
 ### More on feature flags
 
diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md
index 3bc638ca6f2..600afcff1b0 100644
--- a/doc/development/rake_tasks.md
+++ b/doc/development/rake_tasks.md
@@ -270,4 +270,4 @@ To generate GraphQL schema files based on the GitLab schema, run:
 bundle exec rake gitlab:graphql:schema:dump
 ```
 
-This uses graphql-ruby's built-in Rake tasks to generate files in both [IDL](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51) and JSON formats.
+This uses GraphQL Ruby's built-in Rake tasks to generate files in both [IDL](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51) and JSON formats.
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 e1807f2b53f..fbb2a17bef1 100644
--- a/doc/development/testing_guide/end_to_end/best_practices.md
+++ b/doc/development/testing_guide/end_to_end/best_practices.md
@@ -74,7 +74,10 @@ point of failure and so the screenshot would not be captured at the right moment
 
 All QA tests expect to be able to log in at the start of the test.
 
-That's not possible if a test leaves the browser logged in when it finishes. Normally this isn't a problem because [Capybara resets the session after each test](https://github.com/teamcapybara/capybara/blob/9ebc5033282d40c73b0286e60217515fd1bb0b5d/lib/capybara/rspec.rb#L18). But Capybara does that in an `after` block, so when a test logs in in an `after(:context)` block, the browser returns to a logged in state *after* Capybara had logged it out. And so the next test will fail.
+That's not possible if a test leaves the browser logged in when it finishes. Normally this isn't a
+problem because [Capybara resets the session after each test](https://github.com/teamcapybara/capybara/blob/9ebc5033282d40c73b0286e60217515fd1bb0b5d/lib/capybara/rspec.rb#L18).
+But Capybara does that in an `after` block, so when a test logs in within an `after(:context)` block,
+the browser returns to a logged in state *after* Capybara had logged it out. And so the next test will fail.
 
 For an example see: <https://gitlab.com/gitlab-org/gitlab/issues/34736>
 
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 ebf0421617f..c721c934033 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
@@ -458,7 +458,7 @@ By defining the `api_get_path` method, we **would** allow for the [`ApiFabricato
 
 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.
 
-By defining the `api_post_body` method, we we allow for the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request.
+By defining the `api_post_body` method, we allow for the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request.
 
 > Notice that we pass both `color` and `name` attributes in the `api_post_body` since [those are required](../../../api/labels.md#create-a-new-label). Also, notice that we keep them alphabetically organized.
 
diff --git a/doc/development/uploads.md b/doc/development/uploads.md
index b26211901b2..fbdb15d82e1 100644
--- a/doc/development/uploads.md
+++ b/doc/development/uploads.md
@@ -1,7 +1,7 @@
 # Uploads development documentation
 
 [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) has special rules for handling uploads.
-To prevent occupying a ruby process on I/O operations, we process the upload in workhorse, where is cheaper.
+To prevent occupying a Ruby process on I/O operations, we process the upload in workhorse, where is cheaper.
 This process can also directly upload to object storage.
 
 ## The problem description
@@ -40,7 +40,7 @@ We have three challenges here: performance, availability, and scalability.
 
 ### Performance
 
-Rails process are expensive in terms of both CPU and memory. Ruby [global interpreter lock](https://en.wikipedia.org/wiki/Global_interpreter_lock) adds to cost too because the ruby process will spend time on I/O operations on step 3 causing incoming requests to pile up.
+Rails process are expensive in terms of both CPU and memory. Ruby [global interpreter lock](https://en.wikipedia.org/wiki/Global_interpreter_lock) adds to cost too because the Ruby process will spend time on I/O operations on step 3 causing incoming requests to pile up.
 
 In order to improve this, [disk buffered upload](#disk-buffered-upload) was implemented. With this, Rails no longer deals with writing uploaded files to disk.