From ad4d3a075fc338280baaf6240861c9de7aa312ad Mon Sep 17 00:00:00 2001 From: Kamil Trzcinski Date: Fri, 11 Mar 2016 13:39:11 +0100 Subject: Describe special YAML features: the use of anchors and hidden jobs --- doc/ci/yaml/README.md | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 051eaa04152..ec57ac5789e 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -509,6 +509,77 @@ rspec: The cache is provided on best effort basis, so don't expect that cache will be always present. For implementation details please check GitLab Runner. +## Special features + +It's possible special YAML features like anchors and map merging. +Thus allowing to greatly reduce the complexity of `.gitlab-ci.yml`. + +#### Anchors + +You can read more about YAML features [here](https://learnxinyminutes.com/docs/yaml/). + +```yaml +.job_template: &job_definition + image: ruby:2.1 + services: + - postgres + - redis + +test1: + << *job_definition + script: + - test project + +test2: + << *job_definition + script: + - test project +``` + +The above example uses anchors and map merging. +It will create a two jobs: `test1` and `test2` that will have the parameters of `.job_template` and custom `script` defined. + +```yaml +.job_template: &job_definition + script: + - test project + +.postgres_services: + services: &postgres_definition + - postgres + - ruby + +.mysql_services: + services: &mysql_definition + - mysql + - ruby + +test:postgres: + << *job_definition + services: *postgres_definition + +test:mysql: + << *job_definition + services: *mysql_definition +``` + +The above example uses anchors to define two set of services. +It will create a two jobs: `test:postgres` and `test:mysql` that will have the script defined in `.job_template` +and one, the service defined in `.postgres_services` and second the services defined in `.mysql_services`. + +### Hidden jobs + +The jobs that start with `.` will be not processed by GitLab. + +Example of such hidden jobs: +```yaml +.job_name: + script: + - rake spec +``` + +The `.job_name` will be ignored. You can use this feature to ignore jobs, or use them as templates with special YAML features. + ## Validate the .gitlab-ci.yml Each instance of GitLab CI has an embedded debug tool called Lint. -- cgit v1.2.1 From d300ecf8d9e886ee7cff9b883bfcdbdb1e49769b Mon Sep 17 00:00:00 2001 From: Kamil Trzcinski Date: Fri, 11 Mar 2016 13:43:57 +0100 Subject: Allow to pass name of created artifacts archive in `.gitlab-ci.yml` --- doc/ci/yaml/README.md | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index ec57ac5789e..9a1f86cec45 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -453,6 +453,67 @@ release-job: The artifacts will be sent to GitLab after a successful build and will be available for download in the GitLab UI. +#### artifacts:name + +_**Note:** Introduced in GitLab 8.6 and GitLab Runner v1.1.0._ + +The `name` directive allows you to define the name of created artifacts archive. + +Currently the `artifacts` is used. +It may be useful when you will want to download the archive from GitLab. +You could possible have the unique name of every archive. + +The `artifacts:name` variable can use any of the [predefined variables](../variables/README.md). + +--- + +**Example configurations** + +To create a archive with a name of current build: + +```yaml +job: + artifacts: + name: "$CI_BUILD_NAME" +``` + +To create a archive with a name of current branch or tag: + +```yaml +job: + artifacts: + name: "$CI_BUILD_REF_NAME" + untracked: true +``` + +To create a archive with a name of current branch or tag: + +```yaml +job: + artifacts: + name: "${CI_BUILD_NAME}_${CI_BUILD_REF_NAME}" + untracked: true +``` + +To create a archive with a name of stage and branch name: + +```yaml +job: + artifacts: + name: "${CI_BUILD_STAGE}_${CI_BUILD_REF_NAME}" + untracked: true +``` + +If you use **Windows Batch** to run your shell scripts you need to replace +`$` with `%`: + +```yaml +job: + artifacts: + name: "%CI_BUILD_STAGE%_%CI_BUILD_REF_NAME%" + untracked: true +``` + ### cache _**Note:** Introduced in GitLab Runner v0.7.0._ -- cgit v1.2.1 From 9a271d80128451eecc9a301d5e9924c09740be07 Mon Sep 17 00:00:00 2001 From: Kamil Trzcinski Date: Fri, 11 Mar 2016 14:15:13 +0100 Subject: Allow to define on which builds the current one depends on --- doc/ci/yaml/README.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 9a1f86cec45..fb62ed25d64 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -241,6 +241,7 @@ job_name: | tags | no | Defines a list of tags which are used to select runner | | allow_failure | no | Allow build to fail. Failed build doesn't contribute to commit status | | when | no | Define when to run build. Can be `on_success`, `on_failure` or `always` | +| dependencies | no | Define a builds that this build depends on | | artifacts | no | Define list build artifacts | | cache | no | Define list of files that should be cached between subsequent runs | @@ -514,6 +515,60 @@ job: untracked: true ``` +### dependencies + +_**Note:** Introduced in GitLab 8.6 and GitLab Runner v1.1.1._ + +This feature should be used with `artifacts` and allows to define artifacts passing between different builds. + +`artifacts` from previous stages are passed by default. + +To use a feature define `dependencies` in context of the build and pass +a list of all previous builds from which the artifacts should be downloaded. +You can only define a builds from stages that are executed before this one. +Error will be shown if you define builds from current stage or next stages. + +How to use artifacts passing between stages: + +``` +build:osx: + stage: build + script: ... + artifacts: + paths: + - binaries/ + +build:linux: + stage: build + script: ... + artifacts: + paths: + - binaries/ + +test:osx: + stage: test + script: ... + dependencies: + - build:osx + +test:linux: + stage: test + script: ... + dependencies: + - build:linux + +deploy: + stage: deploy + script: ... +``` + +The above will create a build artifacts for two jobs: `build:osx` and `build:linux`. +When executing the `test:osx` the artifacts for `build:osx` will be downloaded and extracted in context of the build. +The same happens for `test:linux` and artifacts from `build:linux`. + +The job `deploy` will download artifacts from all previous builds. +However, only the `build:osx` and `build:linux` exports artifacts so only these will be downloaded. + ### cache _**Note:** Introduced in GitLab Runner v0.7.0._ -- cgit v1.2.1 From 19d1455ac136ab06c2153714761eadfb9ada0f0d Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Sat, 12 Mar 2016 20:22:38 +0200 Subject: Change notes to new styleguide using blockquotes --- doc/ci/yaml/README.md | 37 +++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 16 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index fb62ed25d64..a4d621c0e57 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -116,7 +116,8 @@ Alias for [stages](#stages). ### variables -_**Note:** Introduced in GitLab Runner v0.5.0._ +>**Note:** +Introduced in GitLab Runner v0.5.0. GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in build environment. The variables are stored in the git repository and are meant to @@ -153,7 +154,8 @@ cache: #### cache:key -_**Note:** Introduced in GitLab Runner v1.0.0._ +>**Note:** +Introduced in GitLab Runner v1.0.0. The `key` directive allows you to define the affinity of caching between jobs, allowing to have a single cache for all jobs, @@ -394,12 +396,12 @@ The above script will: ### artifacts -_**Note:** Introduced in GitLab Runner v0.7.0 for non-Windows platforms._ - -_**Note:** Limited Windows support was added in GitLab Runner v.1.0.0. -Currently not all executors are supported._ - -_**Note:** Build artifacts are only collected for successful builds._ +>**Notes:** +> +> - Introduced in GitLab Runner v0.7.0 for non-Windows platforms. +> - Limited Windows support was added in GitLab Runner v.1.0.0. +> - Currently not all executors are supported. +> - Build artifacts are only collected for successful builds. `artifacts` is used to specify list of files and directories which should be attached to build after success. Below are some examples. @@ -456,12 +458,13 @@ be available for download in the GitLab UI. #### artifacts:name -_**Note:** Introduced in GitLab 8.6 and GitLab Runner v1.1.0._ +>**Note:** +Introduced in GitLab 8.6 and GitLab Runner v1.1.0. The `name` directive allows you to define the name of created artifacts archive. -Currently the `artifacts` is used. -It may be useful when you will want to download the archive from GitLab. +Currently the `artifacts` is used. +It may be useful when you will want to download the archive from GitLab. You could possible have the unique name of every archive. The `artifacts:name` variable can use any of the [predefined variables](../variables/README.md). @@ -517,13 +520,14 @@ job: ### dependencies -_**Note:** Introduced in GitLab 8.6 and GitLab Runner v1.1.1._ +>**Note:** +Introduced in GitLab 8.6 and GitLab Runner v1.1.1. This feature should be used with `artifacts` and allows to define artifacts passing between different builds. `artifacts` from previous stages are passed by default. -To use a feature define `dependencies` in context of the build and pass +To use a feature define `dependencies` in context of the build and pass a list of all previous builds from which the artifacts should be downloaded. You can only define a builds from stages that are executed before this one. Error will be shown if you define builds from current stage or next stages. @@ -537,7 +541,7 @@ build:osx: artifacts: paths: - binaries/ - + build:linux: stage: build script: ... @@ -571,7 +575,8 @@ However, only the `build:osx` and `build:linux` exports artifacts so only these ### cache -_**Note:** Introduced in GitLab Runner v0.7.0._ +>**Note:** +Introduced in GitLab Runner v0.7.0. `cache` is used to specify list of files and directories which should be cached between builds. Below are some examples: @@ -665,7 +670,7 @@ It will create a two jobs: `test1` and `test2` that will have the parameters of - postgres - ruby -.mysql_services: +.mysql_services: services: &mysql_definition - mysql - ruby -- cgit v1.2.1 From 49e51753001d0b54adf785792141844c0e89dd70 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Sun, 13 Mar 2016 09:33:10 +0200 Subject: Refactor artifacts:name --- doc/ci/yaml/README.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index a4d621c0e57..83928b81594 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -461,19 +461,16 @@ be available for download in the GitLab UI. >**Note:** Introduced in GitLab 8.6 and GitLab Runner v1.1.0. -The `name` directive allows you to define the name of created artifacts archive. - -Currently the `artifacts` is used. -It may be useful when you will want to download the archive from GitLab. -You could possible have the unique name of every archive. - -The `artifacts:name` variable can use any of the [predefined variables](../variables/README.md). +The `name` directive allows you to define the name of the created artifacts +archive. That way, you can have a unique name of every archive which could be +useful when you'd like to download the archive from GitLab. The `artifacts:name` +variable can make use of any of the [predefined variables](../variables/README.md). --- **Example configurations** -To create a archive with a name of current build: +To create an archive with a name of the current build: ```yaml job: @@ -481,7 +478,8 @@ job: name: "$CI_BUILD_NAME" ``` -To create a archive with a name of current branch or tag: +To create an archive with a name of the current branch or tag including only +the files that are untracked by Git: ```yaml job: @@ -490,7 +488,8 @@ job: untracked: true ``` -To create a archive with a name of current branch or tag: +To create an archive with a name of the current build and the current branch or +tag including only the files that are untracked by Git: ```yaml job: @@ -499,7 +498,7 @@ job: untracked: true ``` -To create a archive with a name of stage and branch name: +To create an archive with a name of the current [stage](#stages) and branch name: ```yaml job: @@ -508,6 +507,8 @@ job: untracked: true ``` +--- + If you use **Windows Batch** to run your shell scripts you need to replace `$` with `%`: -- cgit v1.2.1 From 372abbe7f95d89290d46ef356fc13cc0a886c317 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Sun, 13 Mar 2016 09:34:46 +0200 Subject: Refactor YAML anchors and explain the examples --- doc/ci/yaml/README.md | 104 +++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 82 insertions(+), 22 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 83928b81594..244cec71c8c 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -631,35 +631,78 @@ rspec: The cache is provided on best effort basis, so don't expect that cache will be always present. For implementation details please check GitLab Runner. -## Special features +## Special YAML features -It's possible special YAML features like anchors and map merging. -Thus allowing to greatly reduce the complexity of `.gitlab-ci.yml`. +It's possible to use special YAML features like anchors (`&`), aliases (`*`) +and map merging (`<<`), which will allow you to greatly reduce the complexity +of `.gitlab-ci.yml`. -#### Anchors +Read more about the various [YAML features](https://learnxinyminutes.com/docs/yaml/). -You can read more about YAML features [here](https://learnxinyminutes.com/docs/yaml/). +### Anchors + +>**Note:** +Introduced in GitLab 8.6 and GitLab Runner v1.1.1. + +YAML also has a handy feature called 'anchors', which let you easily duplicate +content across your document. Anchors can be used to duplicate/inherit +properties, and is a perfect example to be used with [hidden jobs](#hidden-jobs) +to provide templates for your jobs. + +The following example uses anchors and map merging. It will create two jobs, +`test1` and `test2`, that will inherit the parameters of `.job_template`, each +having their own custom `script` defined: ```yaml -.job_template: &job_definition +.job_template: &job_definition # Hidden job that defines an anchor named 'job_definition' image: ruby:2.1 services: - postgres - redis test1: - << *job_definition + <<: *job_definition # Merge the contents of the 'job_definition' alias script: - - test project + - test1 project test2: - << *job_definition + <<: *job_definition # Merge the contents of the 'job_definition' alias script: - - test project + - test2 project +``` + +`&` sets up the name of the anchor (`job_definition`), `<<` means "merge the +given hash into the current one", and `*` includes the named anchor +(`job_definition` again). The expanded version looks like this: + +```yaml +.job_template: + image: ruby:2.1 + services: + - postgres + - redis + +test1: + image: ruby:2.1 + services: + - postgres + - redis + script: + - test1 project + +test2: + image: ruby:2.1 + services: + - postgres + - redis + script: + - test2 project ``` -The above example uses anchors and map merging. -It will create a two jobs: `test1` and `test2` that will have the parameters of `.job_template` and custom `script` defined. +Let's see another one example. This time we will use anchors to define two sets +of services. This will create two jobs, `test:postgres` and `test:mysql`, that +will share the `script` directive defined in `.job_template`, and the `services` +directive defined in `.postgres_services` and `.mysql_services` respectively: ```yaml .job_template: &job_definition @@ -685,22 +728,39 @@ test:mysql: services: *mysql_definition ``` -The above example uses anchors to define two set of services. -It will create a two jobs: `test:postgres` and `test:mysql` that will have the script defined in `.job_template` -and one, the service defined in `.postgres_services` and second the services defined in `.mysql_services`. +The expanded version looks like this: -### Hidden jobs +```yaml +.job_template: + script: + - test project -The jobs that start with `.` will be not processed by GitLab. +.postgres_services: + services: + - postgres + - ruby -Example of such hidden jobs: -```yaml -.job_name: +.mysql_services: + services: + - mysql + - ruby + +test:postgres: script: - - rake spec + - test project + services: + - postgres + - ruby + +test:mysql: + script: + - test project + services: + - mysql + - ruby ``` -The `.job_name` will be ignored. You can use this feature to ignore jobs, or use them as templates with special YAML features. +You can see that the hidden jobs are conveniently used as templates. ## Validate the .gitlab-ci.yml -- cgit v1.2.1 From de7c3316b08e7763ac860503578e7fa4c78d2b9d Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Sun, 13 Mar 2016 09:35:40 +0200 Subject: Add hidden jobs --- doc/ci/yaml/README.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 244cec71c8c..5f3a53dcf8e 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -631,6 +631,24 @@ rspec: The cache is provided on best effort basis, so don't expect that cache will be always present. For implementation details please check GitLab Runner. +## Hidden jobs + +>**Note:** +Introduced in GitLab 8.6 and GitLab Runner v1.1.1. + +Jobs that start with a dot (`.`) will be not processed by GitLab CI. You can +use this feature to ignore jobs, or use the +[special YAML features](#special-yaml-features) and transform the hidden jobs +into templates. + +In the following example, `.job_name` will be ignored: + +```yaml +.job_name: + script: + - rake spec +``` + ## Special YAML features It's possible to use special YAML features like anchors (`&`), aliases (`*`) -- cgit v1.2.1 From d8eeeb692ed61454eb06e3276f368f4dc0f11d81 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Sun, 13 Mar 2016 09:57:36 +0200 Subject: Refactor dependencies directive [ci skip] --- doc/ci/yaml/README.md | 47 ++++++++++++++++++++++++++--------------------- 1 file changed, 26 insertions(+), 21 deletions(-) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 5f3a53dcf8e..beaa86250a9 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -236,14 +236,14 @@ job_name: | Keyword | Required | Description | |---------------|----------|-------------| | script | yes | Defines a shell script which is executed by runner | -| stage | no (default: `test`) | Defines a build stage | +| stage | no | Defines a build stage (default: `test`) | | type | no | Alias for `stage` | | only | no | Defines a list of git refs for which build is created | | except | no | Defines a list of git refs for which build is not created | | tags | no | Defines a list of tags which are used to select runner | | allow_failure | no | Allow build to fail. Failed build doesn't contribute to commit status | | when | no | Define when to run build. Can be `on_success`, `on_failure` or `always` | -| dependencies | no | Define a builds that this build depends on | +| dependencies | no | Define other builds that a build depends on so that you can pass artifacts between them| | artifacts | no | Define list build artifacts | | cache | no | Define list of files that should be cached between subsequent runs | @@ -404,7 +404,10 @@ The above script will: > - Build artifacts are only collected for successful builds. `artifacts` is used to specify list of files and directories which should be -attached to build after success. Below are some examples. +attached to build after success. To pass artifacts between different builds, +see [dependencies](#dependencies). + +Below are some examples. Send all files in `binaries` and `.config`: @@ -524,56 +527,58 @@ job: >**Note:** Introduced in GitLab 8.6 and GitLab Runner v1.1.1. -This feature should be used with `artifacts` and allows to define artifacts passing between different builds. +This feature should be used in conjunction with [`artifacts`](#artifacts) and +allows you to define the artifacts to pass between different builds. -`artifacts` from previous stages are passed by default. +Note that `artifacts` from previous [stages](#stages) are passed by default. -To use a feature define `dependencies` in context of the build and pass +To use this feature, define `dependencies` in context of the job and pass a list of all previous builds from which the artifacts should be downloaded. -You can only define a builds from stages that are executed before this one. -Error will be shown if you define builds from current stage or next stages. +You can only define builds from stages that are executed before the current one. +An error will be shown if you define builds from the current stage or next ones. + +--- -How to use artifacts passing between stages: +In the following example, we define two jobs with artifacts, `build:osx` and +`build:linux`. When the `test:osx` is executed, the artifacts from `build:osx` +will be downloaded and extracted in the context of the build. The same happens +for `test:linux` and artifacts from `build:linux`. + +The job `deploy` will download artifacts from all previous builds because of +the [stage](#stages) precedence: ``` build:osx: stage: build - script: ... + script: make build:osx artifacts: paths: - binaries/ build:linux: stage: build - script: ... + script: make build:linux artifacts: paths: - binaries/ test:osx: stage: test - script: ... + script: make test:osx dependencies: - build:osx test:linux: stage: test - script: ... + script: make test:linux dependencies: - build:linux deploy: stage: deploy - script: ... + script: make deploy ``` -The above will create a build artifacts for two jobs: `build:osx` and `build:linux`. -When executing the `test:osx` the artifacts for `build:osx` will be downloaded and extracted in context of the build. -The same happens for `test:linux` and artifacts from `build:linux`. - -The job `deploy` will download artifacts from all previous builds. -However, only the `build:osx` and `build:linux` exports artifacts so only these will be downloaded. - ### cache >**Note:** -- cgit v1.2.1 From 7ebb932070f03e8fb6116b9f54148cae2d782776 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Mon, 14 Mar 2016 10:14:32 +0200 Subject: Add yaml definition to codeblock [ci skip] --- doc/ci/yaml/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index beaa86250a9..4d27c07913d 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -547,7 +547,7 @@ for `test:linux` and artifacts from `build:linux`. The job `deploy` will download artifacts from all previous builds because of the [stage](#stages) precedence: -``` +```yaml build:osx: stage: build script: make build:osx -- cgit v1.2.1 From 543b85a0f555fafa2c5d257872bec25a4c21bd01 Mon Sep 17 00:00:00 2001 From: Jasper Denkers Date: Mon, 14 Mar 2016 13:21:31 +0000 Subject: Fix typo in Ruby CI test and deploy example --- doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/ci') diff --git a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md index c1bb47e4291..f5645d586ae 100644 --- a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md +++ b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md @@ -1,5 +1,5 @@ ## Test and Deploy a ruby application -This example will guide you how to run tests in your Ruby application and deploy it automatiacally as Heroku application. +This example will guide you how to run tests in your Ruby application and deploy it automatically as Heroku application. You can checkout the example [source](https://gitlab.com/ayufan/ruby-getting-started) and check [CI status](https://gitlab.com/ayufan/ruby-getting-started/builds?scope=all). -- cgit v1.2.1 From 090368f6c6edf5727b3e8c5ed69ccaa31e8a2c5f Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Tue, 15 Mar 2016 12:46:21 +0200 Subject: Windows CI support is full since Runner v1.0.0 [ci skip] --- doc/ci/yaml/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/ci') diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 4d27c07913d..5158e3c387c 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -399,7 +399,7 @@ The above script will: >**Notes:** > > - Introduced in GitLab Runner v0.7.0 for non-Windows platforms. -> - Limited Windows support was added in GitLab Runner v.1.0.0. +> - Windows support was added in GitLab Runner v.1.0.0. > - Currently not all executors are supported. > - Build artifacts are only collected for successful builds. -- cgit v1.2.1 From 315d87595404a8bde78566ec51e23b167f041048 Mon Sep 17 00:00:00 2001 From: Mark Pundsack Date: Wed, 16 Mar 2016 18:04:42 +0000 Subject: Fix typo in README.md. --- doc/ci/deployment/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/ci') diff --git a/doc/ci/deployment/README.md b/doc/ci/deployment/README.md index ffd841ca9e7..7d91ce6710f 100644 --- a/doc/ci/deployment/README.md +++ b/doc/ci/deployment/README.md @@ -89,7 +89,7 @@ We also use two secure variables: In GitLab CI 7.12 a new feature was introduced: Secure Variables. Secure Variables can added by going to `Project > Variables > Add Variable`. **This feature requires `gitlab-runner` with version equal or greater than 0.4.0.** -The variables that are defined in the project settings are send along with the build script to the runner. +The variables that are defined in the project settings are sent along with the build script to the runner. The secure variables are stored out of the repository. Never store secrets in your projects' .gitlab-ci.yml. It is also important that secret's value is hidden in the build log. -- cgit v1.2.1