Merge branch 'gt-fix-typos-in-specs-and-docs' into 'master'

Fix typos in specs and docs

See merge request gitlab-org/gitlab-ce!23084

.gitlab/issue_templates/Test plan.md

@@ -64,7 +64,7 @@ Some features might be simple enough that they only involve one Component, while
 more complex features could involve multiple or even all.
 
 Example (from https://gitlab.com/gitlab-org/gitlab-ce/issues/50353):
-* Respository is
+* Repository is
   * Intuitive
     * It's easy to select the desired file template
     * It doesn't require unnecessary actions to save the change
@@ -93,4 +93,4 @@ When adding new automated tests, please keep [testing levels](https://docs.gitla
 in mind.
 -->
 
-/label ~Quality ~"test plan"
+/label ~Quality ~"test plan"

doc/administration/high_availability/redis.md

@@ -684,7 +684,7 @@ cache, queues, and shared_state. To make this work with Sentinel:
     ```
 1. Note that for each persistence class, GitLab will default to using the
    configuration specified in `gitlab_rails['redis_sentinels']` unless
-   overriden by the settings above.
+   overridden by the settings above.
 1. Be sure to include BOTH configuration options for each persistent classes. For example,
    if you choose to configure a cache instance, you must specify both `gitlab_rails['redis_cache_instance']`
    and `gitlab_rails['redis_cache_sentinels']` for GitLab to generate the proper configuration files.

doc/ci/variables/where_variables_can_be_used.md

@@ -17,7 +17,7 @@ There are two places defined variables can be used. On the:
 
 | Definition                           | Can be expanded?  | Expansion place | Description  |
 |--------------------------------------|-------------------|-----------------|--------------|
-| `environment:url`                    | yes               | GitLab           | The variable expansion is made by GitLab's [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism).<ul><li>Supported: all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules)</li><li>Not suported: variables defined in Runner's `config.toml` and variables created in job's `script`</li></ul> |
+| `environment:url`                    | yes               | GitLab           | The variable expansion is made by GitLab's [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism).<ul><li>Supported: all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules)</li><li>Not supported: variables defined in Runner's `config.toml` and variables created in job's `script`</li></ul> |
 | `environment:name`                   | yes               | GitLab           | Similar to `environment:url`, but the variables expansion doesn't support: <ul><li>variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`)</li><li>any other variables related to environment (currently only `CI_ENVIRONMENT_URL`)</li><li>[persisted variables](#persisted-variables)</li></ul> |
 | `variables` | yes               | Runner          | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism) |
 | `image`          | yes               | Runner          | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism) |

doc/development/feature_flags.md

@@ -33,7 +33,7 @@ You can follow the progress on that [in the issue on our issue tracker](https://
 
 In general, it's better to have a group- or user-based gate, and you should prefer
 it over the use of percentage gates. This would make debugging easier, as you
-filter for example logs and errors based on actors too. Futhermore, this allows
+filter for example logs and errors based on actors too. Furthermore, this allows
 for enabling for the `gitlab-org` group first, while the rest of the users
 aren't impacted.
 

doc/development/testing_guide/review_apps.md

@@ -24,7 +24,7 @@ Review Apps are automatically deployed by each pipeline, both in
       [`scripts/review_apps/review-apps.sh`][review-apps.sh]
     - These scripts are basically
       [our official Auto DevOps scripts][Auto-DevOps.gitlab-ci.yml] where the
-      default CNG images are overriden with the images built and stored in the
+      default CNG images are overridden with the images built and stored in the
       [`CNG-mirror` project's registry][cng-mirror-registry].
     - Since we're using [the official GitLab Helm chart][helm-chart], this means
       you get a dedicated environment for your branch that's very close to what it
@@ -33,7 +33,7 @@ Review Apps are automatically deployed by each pipeline, both in
   thanks to the direct link to it from the MR widget. The default username is
   `root` and its password can be found in the 1Password secure note named
   **gitlab-{ce,ee} Review App's root password** (note that there's currently
-  [a bug where the default password seems to be overriden][password-bug]).
+  [a bug where the default password seems to be overridden][password-bug]).
 
 **Additional notes:**