diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-04-20 21:38:24 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-04-20 21:38:24 +0300 |
commit | 983a0bba5d2a042c4a3bbb22432ec192c7501d82 (patch) | |
tree | b153cd387c14ba23bd5a07514c7c01fddf6a78a0 /doc/ci/variables/README.md | |
parent | a2bddee2cdb38673df0e004d5b32d9f77797de64 (diff) |
Add latest changes from gitlab-org/gitlab@12-10-stable-ee
Diffstat (limited to 'doc/ci/variables/README.md')
-rw-r--r-- | doc/ci/variables/README.md | 78 |
1 files changed, 70 insertions, 8 deletions
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index e619a32b90f..99fbc2134a4 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -81,6 +81,8 @@ echo "$KUBE_CA_PEM" > "$(pwd)/kube.ca.pem" kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$(pwd)/kube.ca.pem" ``` +There are [some predefined variables](#custom-variables-validated-by-gitlab) of this type, which may be further validated. They will appear when you add or update a variable. + ##### File type The example above can now be simplified by creating a "File" type variable, and using @@ -116,6 +118,21 @@ If the value does not meet the requirements above, then the CI variable will fai In order to save, either alter the value to meet the masking requirements or disable **Masked** for the variable. +#### Custom variables validated by GitLab + +Some variables are listed in the UI so you can choose them more quickly. +GitLab validates the values of these variables to ensure they are in the correct format. + +| Variable | Allowed Values | Introduced in | +|-------------------------|----------------------------------------------------|---------------| +| `AWS_ACCESS_KEY_ID` | 20 characters: letters, digits | 12.10 | +| `AWS_DEFAULT_REGION` | Any | 12.10 | +| `AWS_SECRET_ACCESS_KEY` | 40 characters: letters, digits, special characters | 12.10 | + +NOTE: **Note:** +When you store credentials, there are security implications. If you are using AWS keys, +for example, follow their [best practices](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html). + ## Getting started To get started with environment variables in the scope of GitLab @@ -482,11 +499,16 @@ value you set for this specific pipeline: ## Environment variables expressions -> Introduced in GitLab 10.7. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/37397) in GitLab 10.7 for [the `only` and `except` CI keywords](../yaml/README.md#onlyexcept-advanced) +> - [Expanded](https://gitlab.com/gitlab-org/gitlab/issues/27863) in GitLab 12.3 with [the `rules` keyword](../yaml/README.md#rules) -It is possible to use variables expressions with only / except policies in -`.gitlab-ci.yml`. By using this approach you can limit what jobs are going to -be created within a pipeline after pushing a code to GitLab. +Variable expressions can be used to limit what jobs are going to be created +within a pipeline after pushing changes to GitLab. + +In `.gitlab-ci.yml`, they work with both + +- [`rules`](../yaml/README.md#rules), which is the recommended approach, and +- [`only` and `except`](../yaml/README.md#onlyexcept-basic), which are candidates for deprecation. This is particularly useful in combination with variables and triggered pipeline variables. @@ -573,8 +595,8 @@ Below you can find supported syntax reference: Examples: - - `$VARIABLE =~ /^content.*/` - - `$VARIABLE_1 !~ /^content.*/` (introduced in GitLab 11.11) + - `=~`: 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). @@ -596,8 +618,48 @@ Below you can find supported syntax reference: 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 standard Ruby 2.5 operation - [precedence](https://ruby-doc.org/core-2.5.0/doc/syntax/precedence_rdoc.html). + 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 `||`. + +### Storing regular expressions in variables + +It is possible to store a regular expression in a variable, to be used for pattern matching: + +```yaml +variables: + STAGINGRELS: '/staging0|staging1/' + +deploy_staging: + script: do.sh deploy staging + environment: staging + rules: + - if: '$RELEASE =~ $STAGINGRELS' +``` + +NOTE: **Note:** +The available regular expression syntax is limited. See [related issue](https://gitlab.com/gitlab-org/gitlab/issues/35438) +for more details. + +If needed, you can use a test pipeline to determine whether a regular expression will +work in a variable. The example below tests the `^mast.*` regular expression directly, +as well as from within a variable: + +```yaml +variables: + MYSTRING: 'master' + MYREGEX: '/^mast.*/' + +testdirect: + script: /bin/true + rules: + - if: '$MYSTRING =~ /^mast.*/' + +testvariable: + script: /bin/true + rules: + - if: '$MYSTRING =~ $MYREGEX' +``` ## Debug logging |