Commit 3791f7bf authored by Evan Read's avatar Evan Read

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
parents 44e44f6c d2d8b935
...@@ -64,7 +64,7 @@ Some features might be simple enough that they only involve one Component, while ...@@ -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. more complex features could involve multiple or even all.
Example (from https://gitlab.com/gitlab-org/gitlab-ce/issues/50353): Example (from https://gitlab.com/gitlab-org/gitlab-ce/issues/50353):
* Respository is * Repository is
* Intuitive * Intuitive
* It's easy to select the desired file template * It's easy to select the desired file template
* It doesn't require unnecessary actions to save the change * 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 ...@@ -93,4 +93,4 @@ When adding new automated tests, please keep [testing levels](https://docs.gitla
in mind. in mind.
--> -->
/label ~Quality ~"test plan" /label ~Quality ~"test plan"
\ No newline at end of file
...@@ -684,7 +684,7 @@ cache, queues, and shared_state. To make this work with Sentinel: ...@@ -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 1. Note that for each persistence class, GitLab will default to using the
configuration specified in `gitlab_rails['redis_sentinels']` unless 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, 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']` 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. and `gitlab_rails['redis_cache_sentinels']` for GitLab to generate the proper configuration files.
......
...@@ -17,7 +17,7 @@ There are two places defined variables can be used. On the: ...@@ -17,7 +17,7 @@ There are two places defined variables can be used. On the:
| Definition | Can be expanded? | Expansion place | Description | | 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> | | `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) | | `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) | | `image` | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism) |
......
...@@ -33,7 +33,7 @@ You can follow the progress on that [in the issue on our issue tracker](https:// ...@@ -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 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 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 for enabling for the `gitlab-org` group first, while the rest of the users
aren't impacted. aren't impacted.
......
...@@ -24,7 +24,7 @@ Review Apps are automatically deployed by each pipeline, both in ...@@ -24,7 +24,7 @@ Review Apps are automatically deployed by each pipeline, both in
[`scripts/review_apps/review-apps.sh`][review-apps.sh] [`scripts/review_apps/review-apps.sh`][review-apps.sh]
- These scripts are basically - These scripts are basically
[our official Auto DevOps scripts][Auto-DevOps.gitlab-ci.yml] where the [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]. [`CNG-mirror` project's registry][cng-mirror-registry].
- Since we're using [the official GitLab Helm chart][helm-chart], this means - 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 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 ...@@ -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 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 `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 **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:** **Additional notes:**
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment