Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2021-06-14 21:10:28 +0300
committerGitLab Bot <gitlab-bot@gitlab.com>2021-06-14 21:10:28 +0300
commitf69bc1dab50e86440bb4ffdc507ca5efd94bf459 (patch)
tree8b4d3da3106fee1271eece2dad1cc5e14052542b /doc/ci/variables
parent81f257d72ef398933453d215019c850f57dae252 (diff)
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/ci/variables')
-rw-r--r--doc/ci/variables/README.md148
-rw-r--r--doc/ci/variables/where_variables_can_be_used.md2
2 files changed, 1 insertions, 149 deletions
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
index cb7669a973c..8b416dd0da9 100644
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
@@ -647,154 +647,6 @@ with `K8S_SECRET_`.
CI/CD variables with multi-line values are not supported.
-## CI/CD variable expressions
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37397) in GitLab 10.7 for [the `only` and `except` CI keywords](../yaml/README.md#onlyvariables--exceptvariables)
-> - [Expanded](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3 with [the `rules` keyword](../yaml/README.md#rules)
-
-Use variable expressions to limit which jobs are created
-in a pipeline after changes are pushed to GitLab.
-
-In `.gitlab-ci.yml`, variable expressions work with both:
-
-- [`rules`](../yaml/README.md#rules), which is the recommended approach, and
-- [`only` and `except`](../yaml/README.md#only--except), which are candidates for deprecation.
-
-This is particularly useful in combination with variables and triggered
-pipeline variables.
-
-```yaml
-deploy:
- script: cap staging deploy
- environment: staging
- only:
- variables:
- - $RELEASE == "staging"
- - $STAGING
-```
-
-Each expression provided is evaluated before a pipeline is created.
-
-If any of the conditions in `variables` evaluates to true when using `only`,
-a new job is created. If any of the expressions evaluates to true
-when `except` is being used, a job is not created.
-
-This follows the usual rules for [`only` / `except` policies](../yaml/README.md#onlyvariables--exceptvariables).
-
-### Syntax of CI/CD variable expressions
-
-Below you can find supported syntax reference.
-
-#### Equality matching using a string
-
-Examples:
-
-- `$VARIABLE == "some value"`
-- `$VARIABLE != "some value"` (introduced in GitLab 11.11)
-
-You can use equality operator `==` or `!=` to compare a variable content to a
-string. We support both, double quotes and single quotes to define a string
-value, so both `$VARIABLE == "some value"` and `$VARIABLE == 'some value'`
-are supported. `"some value" == $VARIABLE` is correct too.
-
-#### Checking for an undefined value
-
-Examples:
-
-- `$VARIABLE == null`
-- `$VARIABLE != null` (introduced in GitLab 11.11)
-
-It sometimes happens that you want to check whether a variable is defined
-or not. To do that, you can compare a variable to `null` keyword, like
-`$VARIABLE == null`. This expression evaluates to true if
-variable is not defined when `==` is used, or to false if `!=` is used.
-
-#### Checking for an empty variable
-
-Examples:
-
-- `$VARIABLE == ""`
-- `$VARIABLE != ""` (introduced in GitLab 11.11)
-
-To check if a variable is defined but empty, compare it to:
-
-- An empty string: `$VARIABLE == ''`
-- A non-empty string: `$VARIABLE != ""`
-
-#### Comparing two variables
-
-Examples:
-
-- `$VARIABLE_1 == $VARIABLE_2`
-- `$VARIABLE_1 != $VARIABLE_2` (introduced in GitLab 11.11)
-
-It is possible to compare two variables. This compares values
-of these variables.
-
-#### Variable presence check
-
-Example: `$STAGING`
-
-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.
-
-#### Regex pattern matching
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/43601) in GitLab 11.0
-
-Examples:
-
-- `=~`: True if pattern is matched. Ex: `$VARIABLE =~ /^content.*/`
-- `!~`: True if pattern is not matched. Ex: `$VARIABLE_1 !~ /^content.*/` ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/61900) in GitLab 11.11)
-
-Variable pattern matching with regular expressions uses the
-[RE2 regular expression syntax](https://github.com/google/re2/wiki/Syntax).
-Expressions evaluate as `true` if:
-
-- Matches are found when using `=~`.
-- Matches are *not* found when using `!~`.
-
-Pattern matching is case-sensitive by default. Use `i` flag modifier, like
-`/pattern/i` to make a pattern case-insensitive.
-
-#### Conjunction / Disjunction
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/62867) in GitLab 12.0
-
-Examples:
-
-- `$VARIABLE1 =~ /^content.*/ && $VARIABLE2 == "something"`
-- `$VARIABLE1 =~ /^content.*/ && $VARIABLE2 =~ /thing$/ && $VARIABLE3`
-- `$VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/ && $VARIABLE3`
-
-It is possible to join multiple conditions using `&&` or `||`. Any of the otherwise
-supported syntax may be used in a conjunctive or disjunctive statement.
-Precedence of operators follows the
-[Ruby 2.5 standard](https://ruby-doc.org/core-2.5.0/doc/syntax/precedence_rdoc.html),
-so `&&` is evaluated before `||`.
-
-#### Parentheses
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230938) in GitLab 13.3.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/238174) in GitLab 13.5.
-
-It is possible to use parentheses to group conditions. Parentheses have the highest
-precedence of all operators. Expressions enclosed in parentheses are evaluated first,
-and the result is used for the rest of the expression.
-
-Many nested parentheses can be used to create complex conditions, and the inner-most
-expressions in parentheses are evaluated first. For an expression to be valid an equal
-number of `(` and `)` need to be used.
-
-Examples:
-
-- `($VARIABLE1 =~ /^content.*/ || $VARIABLE2) && ($VARIABLE3 =~ /thing$/ || $VARIABLE4)`
-- `($VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/) && $VARIABLE3`
-- `$CI_COMMIT_BRANCH == "my-branch" || (($VARIABLE1 == "thing" || $VARIABLE2 == "thing") && $VARIABLE3)`
-
## Debug logging
> Introduced in GitLab Runner 1.7.
diff --git a/doc/ci/variables/where_variables_can_be_used.md b/doc/ci/variables/where_variables_can_be_used.md
index ea54891a99b..c449d2f86da 100644
--- a/doc/ci/variables/where_variables_can_be_used.md
+++ b/doc/ci/variables/where_variables_can_be_used.md
@@ -174,7 +174,7 @@ They are:
- Script execution shell.
- Not supported:
- For definitions where the ["Expansion place"](#gitlab-ciyml-file) is GitLab.
- - In the `only` and `except` [variables expressions](README.md#cicd-variable-expressions).
+ - In the `only` and `except` [variables expressions](../jobs/job_control.md#cicd-variable-expressions).
Some of the persisted variables contain tokens and cannot be used by some definitions
due to security reasons.