Fixed typos

doc/administration/high_availability/redis.md

@@ -323,7 +323,7 @@ The prerequisites for a HA Redis setup are the following:
     # machines to connect to it.
     redis['port'] = 6379
-    # The same password for Redeis authentication you set up for the master node.
+    # The same password for Redis authentication you set up for the master node.
     redis['password'] = 'redis-password-goes-here'
     # The IP of the master Redis node.

doc/administration/job_artifacts.md

@@ -107,7 +107,7 @@ For source installations the following settings are nested under `artifacts:` an
 | Setting | Description | Default |
 |---------|-------------|---------|
 | `enabled` | Enable/disable object storage | `false` |
-| `remote_directory` | The bucket name where Artfacts will be stored| |
+| `remote_directory` | The bucket name where Artifacts will be stored| |
 | `direct_upload` | Set to true to enable direct upload of Artifacts without the need of local shared storage. Option may be removed once we decide to support only single storage for all files. Currently only `Google` provider is supported | `false` |
 | `background_upload` | Set to false to disable automatic upload. Option may be removed once upload is direct to S3 | `true` |
 | `proxy_download` | Set to true to enable proxying all files served. Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data | `false` |
@@ -148,7 +148,7 @@ _The artifacts are stored by default in
     ```
     NOTE: For GitLab 9.4+, if you are using AWS IAM profiles, be sure to omit the
-    AWS access key and secret acces key/value pairs. For example:
+    AWS access key and secret access key/value pairs. For example:
     ```ruby
     gitlab_rails['artifacts_object_store_connection'] = {

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -46,7 +46,7 @@ In this experimental phase, only a few metrics are available:
 | redis_ping_latency_seconds        | Gauge     | 9.4   | Round trip time of the redis ping |
 | user_session_logins_total         | Counter   | 9.4   | Counter of how many users have logged in |
 | filesystem_circuitbreaker_latency_seconds | Gauge | 9.5 | Time spent validating if a storage is accessible |
-| filesystem_circuitbreaker         | Gauge     | 9.5   | Wether or not the circuit for a certain shard is broken or not |
+| filesystem_circuitbreaker         | Gauge     | 9.5   | Whether or not the circuit for a certain shard is broken or not |
 | circuitbreaker_storage_check_duration_seconds | Histogram | 10.3 | Time a single storage probe took |
 ## Metrics shared directory

doc/administration/operations/fast_ssh_key_lookup.md

@@ -31,7 +31,7 @@ GitLab Shell provides a way to authorize SSH users via a fast, indexed lookup
 to the GitLab database. GitLab Shell uses the fingerprint of the SSH key to
 check whether the user is authorized to access GitLab.
-Add the following to your `sshd_config` file. This is usuaully located at
+Add the following to your `sshd_config` file. This is usually located at
 `/etc/ssh/sshd_config`, but it will be `/assets/sshd_config` if you're using
 Omnibus Docker:

doc/administration/uploads.md

@@ -104,7 +104,7 @@ _The uploads are stored by default in
     ```
 >**Note:**
-If you are using AWS IAM profiles, be sure to omit the AWS access key and secret acces key/value pairs.
+If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
     ```ruby
     gitlab_rails['uploads_object_store_connection'] = {

doc/api/README.md

@@ -293,7 +293,7 @@ The following table gives an overview of how the API functions generally behave.
 | `GET`   | Access one or more resources and return the result as JSON. |
 | `POST`  | Return `201 Created` if the resource is successfully created and return the newly created resource as JSON. |
 | `GET` / `PUT` | Return `200 OK` if the resource is accessed or modified successfully. The (modified) result is returned as JSON. |
-| `DELETE` | Returns `204 No Content` if the resuource was deleted successfully. |
+| `DELETE` | Returns `204 No Content` if the resource was deleted successfully. |
 The following table shows the possible return codes for API requests.

doc/api/group_badges.md

@@ -12,7 +12,7 @@ Badges support placeholders that will be replaced in real time in both the link
 - **%{default_branch}**: will be replaced by the project default branch.
 - **%{commit_sha}**: will be replaced by the last project's commit sha.
-Because these enpoints aren't inside a project's context, the information used to replace the placeholders will be
+Because these endpoints aren't inside a project's context, the information used to replace the placeholders will be
 from the first group's project by creation date. If the group hasn't got any project the original URL with the placeholders will be returned.
 ## List all badges of a group

doc/api/pipeline_schedules.md

@@ -108,7 +108,7 @@ POST /projects/:id/pipeline_schedules
 | `description` | string  | yes      | The description of pipeline schedule         |
 | `ref` | string  | yes      | The branch/tag name will be triggered         |
 | `cron ` | string  | yes      | The cron (e.g. `0 1 * * *`) ([Cron syntax](https://en.wikipedia.org/wiki/Cron))       |
-| `cron_timezone ` | string  | no      | The timezone supproted by `ActiveSupport::TimeZone` (e.g. `Pacific Time (US & Canada)`) (default: `'UTC'`)     |
+| `cron_timezone ` | string  | no      | The timezone supported by `ActiveSupport::TimeZone` (e.g. `Pacific Time (US & Canada)`) (default: `'UTC'`)     |
 | `active ` | boolean  | no      | The activation of pipeline schedule. If false is set, the pipeline schedule will deactivated initially (default: `true`) |
 ```sh
@@ -153,7 +153,7 @@ PUT /projects/:id/pipeline_schedules/:pipeline_schedule_id
 | `description` | string  | no      | The description of pipeline schedule         |
 | `ref` | string  | no      | The branch/tag name will be triggered         |
 | `cron ` | string  | no      | The cron (e.g. `0 1 * * *`) ([Cron syntax](https://en.wikipedia.org/wiki/Cron))       |
-| `cron_timezone ` | string  | no      | The timezone supproted by `ActiveSupport::TimeZone` (e.g. `Pacific Time (US & Canada)`) or `TZInfo::Timezone` (e.g. `America/Los_Angeles`)      |
+| `cron_timezone ` | string  | no      | The timezone supported by `ActiveSupport::TimeZone` (e.g. `Pacific Time (US & Canada)`) or `TZInfo::Timezone` (e.g. `America/Los_Angeles`)      |
 | `active ` | boolean  | no      | The activation of pipeline schedule. If false is set, the pipeline schedule will deactivated initially. |
 ```sh

doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md

@@ -509,7 +509,7 @@ and unit tests, all running and deployed at every push to master - with shocking
 Errors can be easily debugged through GitLab's build logs, and within minutes of a successful commit,
 you can see the changes live on your game.
-Setting up Continous Integration and Continuous Deployment from the start with Dark Nova enables
+Setting up Continuous Integration and Continuous Deployment from the start with Dark Nova enables
 rapid but stable development. We can easily test changes in a separate [environment](../../../ci/environments.md#introduction-to-environments-and-deployments),
 or multiple environments if needed. Balancing and updating a multiplayer game can be ongoing
 and tedious, but having faith in a stable deployment with GitLab CI/CD allows

doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md

@@ -30,7 +30,7 @@ and GitLab UI._
 Many components and concepts are similar to Ruby on Rails or Python's Django. High developer
 productivity and high application performance are only a few advantages on learning how to use it.
-Working on the MVC pattern, it's was designed to be modular and flexible. Easy to mantain a growing
+Working on the MVC pattern, it's was designed to be modular and flexible. Easy to maintain a growing
 app is a plus.
 Phoenix can run in any OS where Erlang is supported:
@@ -48,7 +48,7 @@ Check the [Phoenix learning guide][phoenix-learning-guide] for more information.
 ### What is Elixir?
 [Elixir][elixir-site] is a dynamic, functional language created to use all the maturity of Erlang
-(30 years old!) in these days, in an easy way. It has similarities with Ruby, specially on sintax,
+(30 years old!) in these days, in an easy way. It has similarities with Ruby, specially on syntax,
 so Ruby developers are quite excited with the rapid growing of Elixir. A full-stack Ruby developer
 can learn how to use Elixir and Phoenix in just a few weeks!
@@ -162,7 +162,7 @@ productive, because every time we, or our co-workers push any code, GitLab CI/CD
 test the changes, telling us in realtime if anything goes wrong.
 Certainly, when our application starts to grow, we'll need more developers working on the same
-project and this process of building and testing can easely become a mess without proper management.
+project and this process of building and testing can easily become a mess without proper management.
 That's also why GitLab CI/CD is so important to our application. Every time someone pushes its code to
 GitLab, we'll quickly know if their changes broke something or not. We don't need to stop everything
 we're doing to test manually and locally every change our team does.
@@ -237,7 +237,7 @@ Finished in 0.7 seconds
 Randomized with seed 610000
 ```
-Our test was successfull. It's time to push our files to GitLab.
+Our test was successful. It's time to push our files to GitLab.
 ## Configuring CI/CD Pipeline
@@ -302,7 +302,7 @@ template** and select **Elixir**:
     ```
     It's important to install `postgresql-client` to let GitLab CI/CD access PostgreSQL and create our
-    database with the login information provided earlier. More important is to respect the identation,
+    database with the login information provided earlier. More important is to respect the indentation,
     to avoid syntax errors when running the build.
 - And finally, we'll let `mix` session intact.
@@ -333,7 +333,7 @@ mix:
   - mix test
 ```
-For safety, we can check if we get any syntax errors before submiting this file to GitLab. Copy the
+For safety, we can check if we get any syntax errors before submitting this file to GitLab. Copy the
 contents of `.gitlab-ci.yml` and paste it on [GitLab CI/CD Lint tool][ci-lint]. Please note that
 this link will only work for logged in users.
@@ -384,7 +384,7 @@ working properly.
 When we have a growing application with many developers working on it, or when we have an open
 source project being watched and contributed by the community, it is really important to have our
-code permanently working. GitLab CI/CD is a time saving powerfull tool to help us mantain our code
+code permanently working. GitLab CI/CD is a time saving powerful tool to help us maintain our code
 organized and working.
 As we could see in this post, GitLab CI/CD is really really easy to configure and use. We have [many

doc/ci/variables/README.md

@@ -551,7 +551,7 @@ You can find a full list of unsupported variables below:
 - `CI_DEPLOY_USER`
 - `CI_DEPLOY_PASSWORD`
-These variables are also not supported in a contex of a
+These variables are also not supported in a context of a
 [dynamic environment name][dynamic-environments].
 [ce-13784]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784 "Simple protection of CI secret variables"

doc/development/background_migrations.md

@@ -24,7 +24,7 @@ Some examples where background migrations can be useful:
 * Migrating events from one table to multiple separate tables.
 * Populating one column based on JSON stored in another column.
-* Migrating data that depends on the output of exernal services (e.g. an API).
+* Migrating data that depends on the output of external services (e.g. an API).
 ## Isolation
@@ -46,7 +46,7 @@ See [Sidekiq best practices guidelines](https://github.com/mperham/sidekiq/wiki/
 for more details.
 Make sure that in case that your migration job is going to be retried data
-integrity is guarateed.
+integrity is guaranteed.
 ## How It Works

doc/development/doc_styleguide.md

@@ -4,7 +4,7 @@ The documentation style guide defines the markup structure used in
 GitLab documentation. Check the
 [documentation guidelines](writing_documentation.md) for general development instructions.
-Check the GitLab hanbook for the [writing styles guidelines](https://about.gitlab.com/handbook/communication/#writing-style-guidelines).
+Check the GitLab handbook for the [writing styles guidelines](https://about.gitlab.com/handbook/communication/#writing-style-guidelines).
 ## Text
@@ -19,7 +19,7 @@ Check the GitLab hanbook for the [writing styles guidelines](https://about.gitla
 - Unless there's a logical reason not to, add documents in alphabetical order
 - Write in US English
 - Use [single spaces][] instead of double spaces
-- Jump a line between different markups (e.g., after every paragraph, hearder, list, etc)
+- Jump a line between different markups (e.g., after every paragraph, header, list, etc)
 - Capitalize "G" and "L" in GitLab
 - Capitalize feature, products, and methods names. E.g.: GitLab Runner, Geo,
 Issue Boards, Git, Prometheus, Continuous Integration.

doc/development/ee_features.md

@@ -279,7 +279,7 @@ end
 ```
 In `lib/gitlab/visibility_level.rb` this method is used to return the
-allowed visibilty levels:
+allowed visibility levels:
 ```ruby
 def levels_for_user(user = nil)

doc/development/fe_guide/style_guide_js.md

@@ -236,7 +236,7 @@ export class Foo {
 }
 ```
-On the other hand, if a class only needs to extend a third party/add event listeners in some specific cases, they should be initialized oustside of the constructor.
+On the other hand, if a class only needs to extend a third party/add event listeners in some specific cases, they should be initialized outside of the constructor.
 1. Prefer `.map`, `.reduce` or `.filter` over `.forEach`
 A forEach will most likely cause side effects, it will be mutating the array being iterated. Prefer using `.map`,

doc/development/file_storage.md

@@ -84,7 +84,7 @@ The `RecordsUploads::Concern` concern will create an `Upload` entry for every fi
 By including the `ObjectStorage::Concern` in the `GitlabUploader` derived class, you may enable the object storage for this uploader. To enable the object storage
 in your uploader, you need to either 1) include `RecordsUpload::Concern` and prepend `ObjectStorage::Extension::RecordsUploads` or 2) mount the uploader and create a new field named `<mount>_store`.
-The `CarrierWave::Uploader#store_dir` is overriden to
+The `CarrierWave::Uploader#store_dir` is overridden to
  - `GitlabUploader.base_dir` + `GitlabUploader.dynamic_segment` when the store is LOCAL
  - `GitlabUploader.dynamic_segment` when the store is REMOTE (the bucket name is used to namespace)

doc/development/i18n/externalization.md

@@ -270,7 +270,7 @@ If there are merge conflicts in the `gitlab.pot` file, you can delete the file
 and regenerate it using the same command. Confirm that you are not deleting any strings accidentally by looking over the diff.
 The command also updates the translation files for each language: `locale/*/gitlab.po`
-These changes can be discarded, the languange files will be updated by Crowdin
+These changes can be discarded, the language files will be updated by Crowdin
 automatically.
 Discard all of them at once like this:

doc/development/merge_request_performance_guidelines.md

@@ -162,7 +162,7 @@ need for running complex operations to fetch the data. You should use Redis if
 data should be cached for a certain time period instead of the duration of the
 transaction.
-For example, say you process multiple snippets of text containiner username
+For example, say you process multiple snippets of text containing username
 mentions (e.g. `Hello @alice` and `How are you doing @alice?`). By caching the
 user objects for every username we can remove the need for running the same
 query for every mention of `@alice`.

doc/development/ordering_table_columns.md

@@ -30,7 +30,7 @@ example) at the end.
 ## Type Sizes
-While the PostgreSQL docuemntation
+While the PostgreSQL documentation
 (https://www.postgresql.org/docs/current/static/datatype.html) contains plenty
 of information we will list the sizes of common types here so it's easier to
 look them up. Here "word" refers to the word size, which is 4 bytes for a 32

doc/development/testing_guide/testing_levels.md

@@ -28,7 +28,7 @@ records should use stubs/doubles as much as possible.
 | `app/uploaders/` | `spec/uploaders/` | RSpec | |
 | `app/views/` | `spec/views/` | RSpec | |
 | `app/workers/` | `spec/workers/` | RSpec | |
-| `app/assets/javascripts/` | `spec/javascripts/` | Karma | More details in the [Frontent Testing guide](frontend_testing.md) section. |
+| `app/assets/javascripts/` | `spec/javascripts/` | Karma | More details in the [Frontend Testing guide](frontend_testing.md) section. |
 ## Integration tests