Merge branch 'patch-250' into 'master'

Edit CI variables doc to shorten sentences

See merge request gitlab-org/gitlab!44763

doc/ci/variables/README.md

@@ -410,10 +410,12 @@ script:
 
 > Introduced in GitLab 9.4.
 
-You can define per-project or per-group variables
-that are set in the pipeline environment. Group-level variables are stored out of
-the repository (not in `.gitlab-ci.yml`) and are securely passed to GitLab Runner,
-which makes them available during a pipeline run. For Premium users who do **not** use an external key store or who use GitLab's [integration with HashiCorp Vault](../secrets/index.md), we recommend using group environment variables to store secrets like passwords, SSH keys, and credentials.
+You can define per-project or per-group variables that are set in the pipeline environment. Group-level variables are stored out of the repository (not in `.gitlab-ci.yml`). They are securely passed to GitLab Runner, which makes them available during a pipeline run.
+
+We recommend using group environment variables to store secrets (like passwords, SSH keys, and credentials) for Premium users who:
+
+- Do **not** use an external key store.
+- Use GitLab's [integration with HashiCorp Vault](../secrets/index.md).
 
 Group-level variables can be added by:
 
@@ -547,8 +549,7 @@ variables take precedence over those defined in `.gitlab-ci.yml`.
 
 Variable names are limited by the underlying shell used to execute scripts (see [available shells](https://docs.gitlab.com/runner/shells/index.html).
 Each shell has its own unique set of reserved variable names.
-You also want to keep in mind the [scope of environment variables](where_variables_can_be_used.md) to ensure a variable is defined in the scope
-in which you wish to use it.
+Keep in mind the [scope of environment variables](where_variables_can_be_used.md) to ensure a variable is defined in the scope in which you wish to use it.
 
 ## Where variables can be used
 
@@ -682,8 +683,10 @@ Examples:
 - `$VARIABLE == ""`
 - `$VARIABLE != ""` (introduced in GitLab 11.11)
 
-If you want to check whether a variable is defined, but is empty, you can
-simply compare it against an empty string, like `$VAR == ''` or non-empty
+To check if a variable is defined but empty, compare it to:
+
+- An empty string: `$VARIABLE == ''`
+- A non-empty string `$VARIABLE != ""`
 string `$VARIABLE != ""`.
 
 #### Comparing two variables
@@ -700,9 +703,8 @@ of these variables.
 
 Example: `$STAGING`
 
-If you only want to create a job when there is some variable present,
-which means that it is defined and non-empty, you can simply use
-variable name as an expression, like `$STAGING`. If `$STAGING` variable
+To create a job when there is some variable present, meaning it is defined and non-empty,
+use the variable name as an expression, like `$STAGING`. If the `$STAGING` variable
 is defined, and is non empty, expression evaluates to `true`.
 `$STAGING` value needs to be a string, with length higher than zero.
 Variable that contains only whitespace characters is not an empty variable.
@@ -836,9 +838,7 @@ from being leaked into the log unless your script writes them to the screen.
 
 If a job isn't working as expected, this can make the problem difficult to
 investigate; in these cases, you can enable debug tracing in `.gitlab-ci.yml`.
-Available on GitLab Runner v1.7+, this feature enables the shell's execution
-log, resulting in a verbose job log listing all commands that were run,
-variables that were set, and so on.
+Available on GitLab Runner v1.7+, this feature enables the shell's execution log. This results in a verbose job log listing all commands that were run, variables that were set, and so on.
 
 Before enabling this, you should ensure jobs are visible to
 [team members only](../../user/permissions.md#project-features). You should