diff options
Diffstat (limited to 'doc/ci')
| -rw-r--r-- | doc/ci/docker/using_docker_build.md | 2 | ||||
| -rw-r--r-- | doc/ci/examples/deployment/README.md | 86 | ||||
| -rw-r--r-- | doc/ci/triggers/README.md | 24 | ||||
| -rw-r--r-- | doc/ci/triggers/img/triggers_page.png | bin | 5116 -> 110560 bytes | |||
| -rw-r--r-- | doc/ci/variables/README.md | 2 |
5 files changed, 80 insertions, 34 deletions
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index f58ab4d87af..ffa0831290a 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -318,7 +318,7 @@ variables: IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME before_script: - - docker login -u gitlab-ci-token -p $CI_COMMIT_TOKEN $CI_REGISTRY + - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY build: stage: build diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md index d28aa282825..7b0995597c4 100644 --- a/doc/ci/examples/deployment/README.md +++ b/doc/ci/examples/deployment/README.md @@ -1,20 +1,30 @@ -## Using Dpl as deployment tool -Dpl (dee-pee-ell) is a deploy tool made for continuous deployment that's developed and used by Travis CI, but can also be used with GitLab CI. +# Using Dpl as deployment tool -**We recommend to use Dpl, if you're deploying to any of these of these services: https://github.com/travis-ci/dpl#supported-providers**. +[Dpl](https://github.com/travis-ci/dpl) (dee-pee-ell) is a deploy tool made for +continuous deployment that's developed and used by Travis CI, but can also be +used with GitLab CI. -### Requirements -To use Dpl you need at least Ruby 1.8.7 with ability to install gems. +>**Note:** +We recommend to use Dpl if you're deploying to any of these of these services: +https://github.com/travis-ci/dpl#supported-providers. + +## Requirements + +To use Dpl you need at least Ruby 1.9.3 with ability to install gems. + +## Basic usage + +Dpl can be installed on any machine with: -### Basic usage -The Dpl can be installed on any machine with: ``` gem install dpl ``` -This allows you to test all commands from your shell, rather than having to test it on a CI server. +This allows you to test all commands from your local terminal, rather than +having to test it on a CI server. If you don't have Ruby installed you can do it on Debian-compatible Linux with: + ``` apt-get update apt-get install ruby-dev @@ -26,9 +36,10 @@ To use it simply define provider and any additional parameters required by the p For example if you want to use it to deploy your application to heroku, you need to specify `heroku` as provider, specify `api-key` and `app`. There's more and all possible parameters can be found here: https://github.com/travis-ci/dpl#heroku -``` +```yaml staging: - type: deploy + stage: deploy + script: - gem install dpl - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY ``` @@ -37,14 +48,17 @@ In the above example we use Dpl to deploy `my-app-staging` to Heroku server with To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers). -### Using Dpl with Docker +## Using Dpl with Docker + When you use GitLab Runner you most likely configured it to use your server's shell commands. This means that all commands are run in context of local user (ie. gitlab_runner or gitlab_ci_multi_runner). It also means that most probably in your Docker container you don't have the Ruby runtime installed. You will have to install it: -``` + +```yaml staging: - type: deploy + stage: deploy + script: - apt-get update -yq - apt-get install -y ruby-dev - gem install dpl @@ -53,24 +67,31 @@ staging: - master ``` -The first line `apt-get update -yq` updates the list of available packages, where second `apt-get install -y ruby-dev` install `Ruby` runtime on system. +The first line `apt-get update -yq` updates the list of available packages, +where second `apt-get install -y ruby-dev` installs the Ruby runtime on system. The above example is valid for all Debian-compatible systems. -### Usage in staging and production -It's pretty common in developer workflow to have staging (development) and production environment. -If we consider above example: we would like to deploy `master` branch to `staging` and `all tags` to `production` environment. +## Usage in staging and production + +It's pretty common in the development workflow to have staging (development) and +production environments + +Let's consider the following example: we would like to deploy the `master` +branch to `staging` and all tags to the `production` environment. The final `.gitlab-ci.yml` for that setup would look like this: -``` +```yaml staging: - type: deploy + stage: deploy + script: - gem install dpl - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY only: - master - + production: - type: deploy + stage: deploy + script: - gem install dpl - dpl --provider=heroku --app=my-app-production --api-key=$HEROKU_PRODUCTION_API_KEY only: @@ -78,21 +99,28 @@ production: ``` We created two deploy jobs that are executed on different events: + 1. `staging` is executed for all commits that were pushed to `master` branch, 2. `production` is executed for all pushed tags. We also use two secure variables: + 1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app, 2. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app. -### Storing API keys -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 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 job log. +## Storing API keys + +Secure Variables can added by going to your project's +**Settings ➔ CI/CD Pipelines ➔ Secret variables**. 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 project's `.gitlab-ci.yml`. It is also important that the secret's value +is hidden in the job log. + +You access added variable by prefixing it's name with `$` (on non-Windows runners) +or `%` (for Windows Batch runners): -You access added variable by prefixing it's name with `$` (on non-Windows runners) or `%` (for Windows Batch runners): 1. `$SECRET_VARIABLE` - use it for non-Windows runners 2. `%SECRET_VARIABLE%` - use it for Windows Batch runners + +Read more about the [CI variables](../../variables/README.md). diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index ccaee33dc92..e380282f910 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -4,6 +4,7 @@ - [Introduced][ci-229] in GitLab CE 7.14. - GitLab 8.12 has a completely redesigned job permissions system. Read all about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#job-triggers). +- GitLab 9.0 introduced a trigger ownership to solve permission problems. Triggers can be used to force a rebuild of a specific `ref` (branch or tag) with an API call. @@ -21,13 +22,30 @@ overview of the time the triggers were last used.  +## Take ownership + +Each created trigger when run will impersonate their associated user including +their access to projects and their project permissions. + +You can take ownership of existing triggers by clicking *Take ownership*. +From now on the trigger will be run as you. + +## Legacy triggers + +Old triggers, created before 9.0 will be marked as Legacy. Triggers with +the legacy label do not have an associated user and only have access +to the current project. + +Legacy trigger are considered deprecated and will be removed +with one of the future versions of GitLab. + ## Revoke a trigger You can revoke a trigger any time by going at your project's **Settings > Triggers** and hitting the **Revoke** button. The action is irreversible. -## Trigger a job +## Trigger a pipeline > **Note**: Valid refs are only the branches and tags. If you pass a commit SHA as a ref, @@ -63,7 +81,7 @@ below. See the [Examples](#examples) section for more details on how to actually trigger a rebuild. -## Trigger a job from webhook +## Trigger a pipeline from webhook > Introduced in GitLab 8.14. @@ -117,7 +135,7 @@ curl --request POST \ "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline?token=TOKEN&ref=master" ``` -### Triggering a job within `.gitlab-ci.yml` +### Triggering a pipeline within `.gitlab-ci.yml` You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that you have two projects, A and B, and you want to trigger a rebuild on the `master` diff --git a/doc/ci/triggers/img/triggers_page.png b/doc/ci/triggers/img/triggers_page.png Binary files differindex 8ebf68d0384..eafd8519a23 100644 --- a/doc/ci/triggers/img/triggers_page.png +++ b/doc/ci/triggers/img/triggers_page.png diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index 4e9094cb0f1..b35caf672a8 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -352,7 +352,7 @@ Example values: export CI_JOB_ID="50" export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a" export CI_COMMIT_REF_NAME="master" -export CI_REPOSITORY="https://gitab-ci-token:abcde-1234ABCD5678ef@example.com/gitlab-org/gitlab-ce.git" +export CI_REPOSITORY_URL="https://gitab-ci-token:abcde-1234ABCD5678ef@example.com/gitlab-org/gitlab-ce.git" export CI_COMMIT_TAG="1.0.0" export CI_JOB_NAME="spec:other" export CI_JOB_STAGE="test" |
