From 6ed2370b850ea6db22649ed32940acdc2010877b Mon Sep 17 00:00:00 2001 From: Grzegorz Bizon Date: Wed, 28 Mar 2018 14:00:53 +0200 Subject: Add basic docs for variables expressions feature --- doc/ci/variables/README.md | 62 ++++++++++++++++++++++++++++++++++++++++++++++ doc/ci/yaml/README.md | 26 ++++++++++++++++--- 2 files changed, 85 insertions(+), 3 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index bd4aeb006bd..25ec12a5b3e 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -449,6 +449,67 @@ export CI_REGISTRY_USER="gitlab-ci-token" export CI_REGISTRY_PASSWORD="longalfanumstring" ``` +## Variables expressions + +> Variables expressions were added in GitLab 10.7. + +It is possible to use variables expressions with only / except policies in +`.gitlab-ci.yml`. By using this approach you can limit what builds are going to +be created within a pipeline after pushing code to GitLab. + +This is particularly useful in combination with secret variables and triggered +pipeline variables. + +```yaml +deploy: + script: cap staging deploy + environment: staging + only: + variables: + - $RELEASE == "staging" + - $STAGING +``` + +Each provided variables expression is going to be evaluated before creating +a pipeline. + +If any of the conditions in `variables` evaluates to truth when using `only`, +new build is going to be created. If any of the expressions evaluates to truth +when `except` is being used, a build is not going to be created. + +This follows usual rules for [`only` / `except` policies][build policies]. + +### Supported syntax + +Below you can find currently supported syntax reference: + +1. Equality matching using a string. + + Example: `$VARIABLE == "some value"` + + You can use equality operator `==` 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. + +1. Checking for an undefined value. + + It sometimes happens that you want to check whether variable is defined or + not. To do that, you can compare variable to `null` value, like + `$VARIABLE == null`. This expression is going to evaluate to truth if + variable is not set. + +1. Comparing two variables. + + It is possible to compare two variables. `$VARIABLE_1 == $VARIABLE_2`. + +1. Variable presence check. + + 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 + is defined, and is non empty, expression will evaluate to truth. + [ce-13784]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784 "Simple protection of CI secret variables" [eep]: https://about.gitlab.com/products/ "Available only in GitLab Premium" [envs]: ../environments.md @@ -459,3 +520,4 @@ export CI_REGISTRY_PASSWORD="longalfanumstring" [triggered]: ../triggers/README.md [triggers]: ../triggers/README.md#pass-job-variables-to-a-trigger [subgroups]: ../../user/group/subgroups/index.md +[build policies]: ../yaml/#only-and-except-complex diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 7184f3367be..2171da419d1 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -315,9 +315,14 @@ policy configuration. GitLab now supports both, simple and complex strategies, so it is possible to use an array and a hash configuration scheme. -Two keys are now available: `refs` and `kubernetes`. Refs strategy equals to -simplified only/except configuration, whereas kubernetes strategy accepts only -`active` keyword. +Three keys are now available: `refs`, `kubernetes` and `variables`. +Refs strategy equals to simplified only/except configuration, whereas +kubernetes strategy accepts only `active` keyword. + +`variables` keyword is used to define variables expressions. In other words +you can use predefined variables / secret variables / project / group or +environment-scoped variables to define an expression GitLab is going to +evaluate in order to decide whether a job should be created or not. See the example below. Job is going to be created only when pipeline has been scheduled or runs for a `master` branch, and only if kubernetes service is @@ -332,6 +337,20 @@ job: kubernetes: active ``` +Example of using variables expressions: + +```yaml +deploy: + only: + refs: + - branches + variables: + - $RELEASE == "staging" + - $STAGING +``` + +Learn more about variables expressions on [separate page][variables-expressions]. + ## `tags` `tags` is used to select specific Runners from the list of all Runners that are @@ -1549,3 +1568,4 @@ CI with various languages. [ce-7447]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7447 [ce-12909]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12909 [schedules]: ../../user/project/pipelines/schedules.md +[variables expressions]: ../variables#variables-expressions -- cgit v1.2.1 From 659933586c4e448cd34f279d4987af332a0bcade Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Thu, 29 Mar 2018 09:30:39 +0200 Subject: Refactor the browser performance testing docs From my experience in setting this up https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/231/diffs --- doc/ci/examples/browser_performance.md | 93 ++++++++++++++++++++++++++-------- 1 file changed, 73 insertions(+), 20 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/examples/browser_performance.md b/doc/ci/examples/browser_performance.md index 42dc6ef36ba..691370d7195 100644 --- a/doc/ci/examples/browser_performance.md +++ b/doc/ci/examples/browser_performance.md @@ -1,22 +1,28 @@ # Browser Performance Testing with the Sitespeed.io container -This example shows how to run the [Sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) on your code by using -GitLab CI/CD and [Sitespeed.io](https://www.sitespeed.io) using Docker-in-Docker. +This example shows how to run the +[Sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) on +your code by using GitLab CI/CD and [Sitespeed.io](https://www.sitespeed.io) +using Docker-in-Docker. -First, you need a GitLab Runner with the [docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor). - -Once you set up the Runner, add a new job to `.gitlab-ci.yml`, called `performance`: +First, you need a GitLab Runner with the +[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor). +Once you set up the Runner, add a new job to `.gitlab-ci.yml`, called +`performance`: ```yaml +performance: stage: performance image: docker:git + variables: + URL: https://example.com services: - docker:dind script: - mkdir gitlab-exporter - - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/10-5/index.js + - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js - mkdir sitespeed-results - - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results https://my.website.com + - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL - mv sitespeed-results/data/performance.json performance.json artifacts: paths: @@ -24,37 +30,84 @@ Once you set up the Runner, add a new job to `.gitlab-ci.yml`, called `performan - sitespeed-results/ ``` -This will create a `performance` job in your CI/CD pipeline and will run Sitespeed.io against the webpage you define. The GitLab plugin for Sitespeed.io is downloaded in order to export key metrics to JSON. The full HTML Sitespeed.io report will also be saved as an artifact, and if you have Pages enabled it can be viewed directly in your browser. For further customization options of Sitespeed.io, including the ability to provide a list of URLs to test, please consult their [documentation](https://www.sitespeed.io/documentation/sitespeed.io/configuration/). +The above example will: + +1. Create a `performance` job in your CI/CD pipeline and will run + Sitespeed.io against the webpage you defined in `URL`. +1. The [GitLab plugin](https://gitlab.com/gitlab-org/gl-performance) for + Sitespeed.io is downloaded in order to export key metrics to JSON. The full + HTML Sitespeed.io report will also be saved as an artifact, and if you have + [GitLab Pages](../../user/project/pages/index.md) enabled, it can be viewed + directly in your browser. + +For further customization options of Sitespeed.io, including the ability to +provide a list of URLs to test, please consult +[their documentation](https://www.sitespeed.io/documentation/sitespeed.io/configuration/). -For [GitLab Premium](https://about.gitlab.com/products/) users, key metrics are automatically -extracted and shown right in the merge request widget. Learn more about [Browser Performance Testing](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html). +TIP: **Tip:** +For [GitLab Premium](https://about.gitlab.com/pricing/) users, key metrics are automatically +extracted and shown right in the merge request widget. Learn more about +[Browser Performance Testing](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html). ## Performance testing on Review Apps -The above CI YML is great for testing against static environments, and it can be extended for dynamic environments. There are a few extra steps to take to set this up: -1. The `performance` job should run after the environment has started. -1. In the `deploy` job, persist the hostname so it is available to the `performance` job. The same can be done for static environments like staging and production to unify the code path. Saving it as an artifact is as simple as `echo $CI_ENVIRONMENT_URL > environment_url.txt`. -1. In the `performance` job read the artifact into an environment variable, like `$CI_ENVIRONMENT_URL`, and use it to parameterize the test URL's. -1. Now you can run the Sitespeed.io container against the desired hostname and paths. +The above CI YML is great for testing against static environments, and it can +be extended for dynamic environments. There are a few extra steps to take to +set this up: -A simple `performance` job would look like: +1. The `performance` job should run after the dynamic environment has started. +1. In the `review` job, persist the hostname and upload it as an artifact so + it's available to the `performance` job (the same can be done for static + environments like staging and production to unify the code path). Saving it + as an artifact is as simple as `echo $CI_ENVIRONMENT_URL > environment_url.txt` + in your job's `script`. +1. In the `performance` job, read the previous artifact into an environment + variable, like `$CI_ENVIRONMENT_URL`, and use it to parameterize the test + URLs. +1. You can now run the Sitespeed.io container against the desired hostname and + paths. + +Your `.gitlab-ci.yml` file would look like: ```yaml +stages: + - deploy + - performance + +review: + stage: deploy + environment: + name: review/$CI_COMMIT_REF_SLUG + url: http://$CI_COMMIT_REF_SLUG.$APPS_DOMAIN + script: + - run_deploy_script + - echo $CI_ENVIRONMENT_URL > environment_url.txt + artifacts: + paths: + - environment_url.txt + only: + - branches + except: + - master + +performance: stage: performance image: docker:git services: - docker:dind + dependencies: + - review script: - export CI_ENVIRONMENT_URL=$(cat environment_url.txt) - mkdir gitlab-exporter - - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/10-5/index.js + - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js - mkdir sitespeed-results - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results "$CI_ENVIRONMENT_URL" - mv sitespeed-results/data/performance.json performance.json artifacts: paths: - - performance.json - - sitespeed-results/ + - performance.json + - sitespeed-results/ ``` -A complete example can be found in our [Auto DevOps CI YML](https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml). \ No newline at end of file +A complete example can be found in our [Auto DevOps CI YML](https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml). -- cgit v1.2.1 From f4d81536ac26f75e0aad248ad95c31c9e1f2680b Mon Sep 17 00:00:00 2001 From: Grzegorz Bizon Date: Thu, 29 Mar 2018 11:25:49 +0200 Subject: Copy-edit documentation for variables expressions --- doc/ci/variables/README.md | 20 ++++++++++++-------- doc/ci/yaml/README.md | 3 +-- 2 files changed, 13 insertions(+), 10 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index 25ec12a5b3e..9f268f47e6f 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -474,16 +474,16 @@ Each provided variables expression is going to be evaluated before creating a pipeline. If any of the conditions in `variables` evaluates to truth when using `only`, -new build is going to be created. If any of the expressions evaluates to truth -when `except` is being used, a build is not going to be created. +a new job is going to be created. If any of the expressions evaluates to truth +when `except` is being used, a job is not going to be created. -This follows usual rules for [`only` / `except` policies][build policies]. +This follows usual rules for `only` / `except` policies. ### Supported syntax Below you can find currently supported syntax reference: -1. Equality matching using a string. +1. Equality matching using a string Example: `$VARIABLE == "some value"` @@ -492,18 +492,23 @@ Below you can find currently supported syntax reference: value, so both `$VARIABLE == "some value"` and `$VARIABLE == 'some value'` are supported. `"some value" == $VARIABLE` is correct too. -1. Checking for an undefined value. +1. Checking for an undefined value It sometimes happens that you want to check whether variable is defined or not. To do that, you can compare variable to `null` value, like `$VARIABLE == null`. This expression is going to evaluate to truth if variable is not set. -1. Comparing two variables. +1. Checking for an empty variable + + If you want to check whether a variable is defined, but is empty, you can + simply compare it against an empty string, like `$VAR == ''`. + +1. Comparing two variables It is possible to compare two variables. `$VARIABLE_1 == $VARIABLE_2`. -1. Variable presence check. +1. Variable presence check 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 @@ -520,4 +525,3 @@ Below you can find currently supported syntax reference: [triggered]: ../triggers/README.md [triggers]: ../triggers/README.md#pass-job-variables-to-a-trigger [subgroups]: ../../user/group/subgroups/index.md -[build policies]: ../yaml/#only-and-except-complex diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 2171da419d1..3382fbc2d12 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -349,7 +349,7 @@ deploy: - $STAGING ``` -Learn more about variables expressions on [separate page][variables-expressions]. +Learn more about variables expressions on a separate page. ## `tags` @@ -1568,4 +1568,3 @@ CI with various languages. [ce-7447]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7447 [ce-12909]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12909 [schedules]: ../../user/project/pipelines/schedules.md -[variables expressions]: ../variables#variables-expressions -- cgit v1.2.1 From 1893625bbd71ba39bee436e84bbf6a42836c4534 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Tue, 27 Mar 2018 13:34:55 +0200 Subject: Provide clarification on mirrored repositories for pipelines --- doc/ci/pipelines.md | 8 ++++++-- doc/ci/quick_start/README.md | 5 +++++ doc/ci/yaml/README.md | 5 +++++ 3 files changed, 16 insertions(+), 2 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md index 856d7f264e4..301cccc80a3 100644 --- a/doc/ci/pipelines.md +++ b/doc/ci/pipelines.md @@ -2,6 +2,11 @@ > Introduced in GitLab 8.8. +NOTE: **Note:** +If you have a [mirrored repository where GitLab pulls from](https://docs.gitlab.com/ee/workflow/repository_mirroring.html#pulling-from-a-remote-repository), +you may need to enable pipeline triggering in your project's +**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**. + ## Pipelines A pipeline is a group of [jobs][] that get executed in [stages][](batches). @@ -121,9 +126,8 @@ The basic requirements is that there are two numbers separated with one of the following (you can even use them interchangeably): - a space -- a forward slash (`/`) +- a slash (`/`) - a colon (`:`) -- a dot (`.`) >**Note:** More specifically, [it uses][regexp] this regular expression: `\d+[\s:\/\\]+\d+\s*`. diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md index f64e868d390..fec0ff87326 100644 --- a/doc/ci/quick_start/README.md +++ b/doc/ci/quick_start/README.md @@ -126,6 +126,11 @@ git push origin master Now if you go to the **Pipelines** page you will see that the pipeline is pending. +NOTE: **Note:** +If you have a [mirrored repository where GitLab pulls from](https://docs.gitlab.com/ee/workflow/repository_mirroring.html#pulling-from-a-remote-repository), +you may need to enable pipeline triggering in your project's +**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**. + You can also go to the **Commits** page and notice the little pause icon next to the commit SHA. diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index c2b06e53c2f..6953e0ce79d 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -10,6 +10,11 @@ of your repository and contains definitions of how your project should be built. If you want a quick introduction to GitLab CI, follow our [quick start guide](../quick_start/README.md). +NOTE: **Note:** +If you have a [mirrored repository where GitLab pulls from](https://docs.gitlab.com/ee/workflow/repository_mirroring.html#pulling-from-a-remote-repository), +you may need to enable pipeline triggering in your project's +**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**. + ## Jobs The YAML file defines a set of jobs with constraints stating when they should -- cgit v1.2.1 From 64ef7517af80ff3aeffe45af79549ab84b4bf040 Mon Sep 17 00:00:00 2001 From: Patrick Deden Date: Thu, 1 Feb 2018 12:20:03 +0000 Subject: Envoy.blade.php syntax fixed --- doc/ci/examples/laravel_with_gitlab_and_envoy/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/ci') diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md index b62874ef029..1f9b9d53fc1 100644 --- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md +++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md @@ -190,7 +190,7 @@ To start, we create an `Envoy.blade.php` in the root of our app with a simple ta ```php @servers(['web' => 'remote_username@remote_host']) -@task('list', [on => 'web']) +@task('list', ['on' => 'web']) ls -l @endtask ``` -- cgit v1.2.1 From a086945275bb2c3ea7d75f9e26d85743754f0c40 Mon Sep 17 00:00:00 2001 From: Olivier Gonzalez Date: Tue, 3 Apr 2018 19:19:00 +0000 Subject: Update Security Products examples documentation --- doc/ci/examples/code_climate.md | 7 ++++--- doc/ci/examples/container_scanning.md | 4 ++-- doc/ci/examples/dast.md | 25 ++++++++++++++++++++++++- 3 files changed, 30 insertions(+), 6 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/examples/code_climate.md b/doc/ci/examples/code_climate.md index 64a759a9a99..92317c77427 100644 --- a/doc/ci/examples/code_climate.md +++ b/doc/ci/examples/code_climate.md @@ -9,11 +9,12 @@ Once you set up the Runner, add a new job to `.gitlab-ci.yml`, called `codequali ```yaml codequality: - image: docker:latest + image: docker:stable variables: - DOCKER_DRIVER: overlay + DOCKER_DRIVER: overlay2 + allow_failure: true services: - - docker:dind + - docker:stable-dind script: - export SP_VERSION=$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/') - docker run --env SOURCE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock "registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code diff --git a/doc/ci/examples/container_scanning.md b/doc/ci/examples/container_scanning.md index 3437b63748a..c58efc7392a 100644 --- a/doc/ci/examples/container_scanning.md +++ b/doc/ci/examples/container_scanning.md @@ -11,7 +11,7 @@ called `sast:container`: ```yaml sast:container: - image: docker:latest + image: docker:stable variables: DOCKER_DRIVER: overlay2 ## Define two new variables based on GitLab's CI/CD predefined variables @@ -20,7 +20,7 @@ sast:container: CI_APPLICATION_TAG: $CI_COMMIT_SHA allow_failure: true services: - - docker:dind + - docker:stable-dind script: - docker run -d --name db arminc/clair-db:latest - docker run -p 6060:6060 --link db:postgres -d --name clair arminc/clair-local-scan:v2.0.1 diff --git a/doc/ci/examples/dast.md b/doc/ci/examples/dast.md index 96de0f5ff5c..8df223ee560 100644 --- a/doc/ci/examples/dast.md +++ b/doc/ci/examples/dast.md @@ -14,9 +14,10 @@ called `dast`: ```yaml dast: - image: owasp/zap2docker-stable + image: registry.gitlab.com/gitlab-org/security-products/zaproxy variables: website: "https://example.com" + allow_failure: true script: - mkdir /zap/wrk/ - /zap/zap-baseline.py -J gl-dast-report.json -t $website || true @@ -30,6 +31,28 @@ the tests on the URL defined in the `website` variable (change it to use your own) and finally write the results in the `gl-dast-report.json` file. You can then download and analyze the report artifact in JSON format. +It's also possible to authenticate the user before performing DAST checks: + +```yaml +dast: + image: registry.gitlab.com/gitlab-org/security-products/zaproxy + variables: + website: "https://example.com" + login_url: "https://example.com/sign-in" + allow_failure: true + script: + - mkdir /zap/wrk/ + - /zap/zap-baseline.py -J gl-dast-report.json -t $website \ + --auth-url $login_url \ + --auth-username "john.doe@example.com" \ + --auth-password "john-doe-password" || true + - cp /zap/wrk/gl-dast-report.json . + artifacts: + paths: [gl-dast-report.json] +``` +See [zaproxy documentation](https://gitlab.com/gitlab-org/security-products/zaproxy) +to learn more about authentication settings. + TIP: **Tip:** Starting with [GitLab Ultimate][ee] 10.4, this information will be automatically extracted and shown right in the merge request widget. To do -- cgit v1.2.1 From 323bac4a6e1de5d9ba9c1cb3a2868f514888c44a Mon Sep 17 00:00:00 2001 From: Grzegorz Bizon Date: Thu, 5 Apr 2018 11:30:02 +0200 Subject: Improve docs about pipeline variables expressions --- doc/ci/variables/README.md | 55 ++++++++++++++++++++++++++++++++++++---------- doc/ci/yaml/README.md | 3 ++- 2 files changed, 46 insertions(+), 12 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index 9f268f47e6f..381405a9db9 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -454,8 +454,8 @@ export CI_REGISTRY_PASSWORD="longalfanumstring" > Variables expressions were added in GitLab 10.7. It is possible to use variables expressions with only / except policies in -`.gitlab-ci.yml`. By using this approach you can limit what builds are going to -be created within a pipeline after pushing code to GitLab. +`.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. This is particularly useful in combination with secret variables and triggered pipeline variables. @@ -470,22 +470,21 @@ deploy: - $STAGING ``` -Each provided variables expression is going to be evaluated before creating -a pipeline. +Each expression provided is going to be evaluated before creating a pipeline. If any of the conditions in `variables` evaluates to truth when using `only`, a new job is going to be created. If any of the expressions evaluates to truth when `except` is being used, a job is not going to be created. -This follows usual rules for `only` / `except` policies. +This follows usual rules for [`only` / `except` policies][builds-policies]. ### Supported syntax -Below you can find currently supported syntax reference: +Below you can find supported syntax reference: 1. Equality matching using a string - Example: `$VARIABLE == "some value"` + > Example: `$VARIABLE == "some value"` You can use equality operator `==` to compare a variable content to a string. We support both, double quotes and single quotes to define a string @@ -494,26 +493,59 @@ Below you can find currently supported syntax reference: 1. Checking for an undefined value - It sometimes happens that you want to check whether variable is defined or - not. To do that, you can compare variable to `null` value, like + > Example: `$VARIABLE == null` + + 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 is going to evaluate to truth if - variable is not set. + variable is not defined. 1. Checking for an empty variable + > Example: `$VARIABLE == ""` + If you want to check whether a variable is defined, but is empty, you can simply compare it against an empty string, like `$VAR == ''`. 1. Comparing two variables - It is possible to compare two variables. `$VARIABLE_1 == $VARIABLE_2`. + > Example: `$VARIABLE_1 == $VARIABLE_2` + + It is possible to compare two variables. This is going to compare values + of these variables. 1. Variable presence check + > 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 is defined, and is non empty, expression will evaluate to truth. + `$STAGING` value needs to a string, with length higher than zero. + Variable that contains only whitespace characters is not an empty variable. + +### Unsupported predefined variables + +Because GitLab evaluates variables before creating jobs, we do not support a +few variables that depend on persistence layer, like `$CI_JOB_ID`. + +Environments (like `production` or `staging`) are also being created based on +what jobs pipeline consists of, thus some environment-specific variables are +not supported as well. + +We do not support variables containing tokens because of security reasons. + +You can find a full list of unsupported variables below: + +- `CI_JOB_ID` +- `CI_JOB_TOKEN` +- `CI_BUILD_ID` +- `CI_BUILD_TOKEN` +- `CI_REGISTRY_USER` +- `CI_REGISTRY_PASSWORD` +- `CI_REPOSITORY_URL` +- `CI_ENVIRONMENT_URL` [ce-13784]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784 "Simple protection of CI secret variables" [eep]: https://about.gitlab.com/products/ "Available only in GitLab Premium" @@ -525,3 +557,4 @@ Below you can find currently supported syntax reference: [triggered]: ../triggers/README.md [triggers]: ../triggers/README.md#pass-job-variables-to-a-trigger [subgroups]: ../../user/group/subgroups/index.md +[builds-policies]: ../yaml/README.md#only-and-except-complex diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index be114e7008e..68aa64b3834 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -354,7 +354,7 @@ deploy: - $STAGING ``` -Learn more about variables expressions on a separate page. +Learn more about variables expressions on [a separate page][variables-expressions]. ## `tags` @@ -1574,3 +1574,4 @@ CI with various languages. [ce-7447]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7447 [ce-12909]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12909 [schedules]: ../../user/project/pipelines/schedules.md +[variables-expressions]: ../variables/README.md#variables-expressions -- cgit v1.2.1 From 847f1667c89831213859d62ca66fbd55181fb129 Mon Sep 17 00:00:00 2001 From: Grzegorz Bizon Date: Fri, 6 Apr 2018 10:41:58 +0200 Subject: Document unsupported variables for dynamic environments --- doc/ci/environments.md | 15 ++++++++++++--- doc/ci/variables/README.md | 4 ++++ 2 files changed, 16 insertions(+), 3 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/environments.md b/doc/ci/environments.md index 58c4a71cef9..b3d9f0bc96c 100644 --- a/doc/ci/environments.md +++ b/doc/ci/environments.md @@ -247,10 +247,19 @@ declaring their names dynamically in `.gitlab-ci.yml`. Dynamic environments is the basis of [Review apps](review_apps/index.md). >**Note:** -The `name` and `url` parameters can use any of the defined CI variables, +The `name` and `url` parameters can use most of the defined CI variables, including predefined, secure variables and `.gitlab-ci.yml` -[`variables`](yaml/README.md#variables). -You however cannot use variables defined under `script` or on the Runner's side. +[`variables`](yaml/README.md#variables). You however cannot use variables +defined under `script` or on the Runner's side. There are other variables that +are unsupported in environment name context: +- `CI_JOB_ID` +- `CI_JOB_TOKEN` +- `CI_BUILD_ID` +- `CI_BUILD_TOKEN` +- `CI_REGISTRY_USER` +- `CI_REGISTRY_PASSWORD` +- `CI_REPOSITORY_URL` +- `CI_ENVIRONMENT_URL` GitLab Runner exposes various [environment variables][variables] when a job runs, and as such, you can use them as environment names. Let's add another job in diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index 381405a9db9..4a504a98902 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -547,6 +547,9 @@ You can find a full list of unsupported variables below: - `CI_REPOSITORY_URL` - `CI_ENVIRONMENT_URL` +These variables are also not supported in a contex of a +[dynamic environment name][dynamic-environments]. + [ce-13784]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784 "Simple protection of CI secret variables" [eep]: https://about.gitlab.com/products/ "Available only in GitLab Premium" [envs]: ../environments.md @@ -558,3 +561,4 @@ You can find a full list of unsupported variables below: [triggers]: ../triggers/README.md#pass-job-variables-to-a-trigger [subgroups]: ../../user/group/subgroups/index.md [builds-policies]: ../yaml/README.md#only-and-except-complex +[dynamic-environments]: ../environments.md#dynamic-environments -- cgit v1.2.1