summaryrefslogtreecommitdiff
path: root/doc/ci
diff options
context:
space:
mode:
authorGrzegorz Bizon <grzesiek.bizon@gmail.com>2017-04-03 09:36:09 +0200
committerGrzegorz Bizon <grzesiek.bizon@gmail.com>2017-04-03 09:36:09 +0200
commitfc550b398be6cdc4584dad79411929305815ffaa (patch)
tree0995b6990fa3599dddfed5bd2720589731bcdf31 /doc/ci
parent83d1fe9b5aeb947c1387666205ecaca81f2bf3a2 (diff)
parente7e9307219d1c81427f95444b36471c519dc06c2 (diff)
downloadgitlab-ce-fc550b398be6cdc4584dad79411929305815ffaa.tar.gz
Merge branch 'master' into feature/multi-level-container-registry-images
* master: (230 commits) Fix N+1 query in loading pipelines in merge requests Fix Spinach and Capybara dependencies Prevent users from disconnecting gitlab account from CAS 30276 Move issue, mr, todos next to profile dropdown in top nav Refactor SearchController#show Properly eagerly-load the Capybara server for JS feature specs only Updating documentation to include a missing step in the update procedure Eager-load the Capybara server to prevent timeouts Increase Capybara's timeout Add metrics button to Environment Overview page Fix link to Jira service documentation Handle parsing OpenBSD ps output properly to display sidekiq infos on ... Eliminate unnecessary queries that add ~500 ms of load time for a large issue 20914 Limits line length for project home page Allow users to import GitHub projects to subgroups Update dpl CI example Fix the docs:check:links job Don't clean up the gitlab-test-fork_bare repo Make GitLab use Gitaly for commit_is_ancestor Remove unnecessary ORDER BY clause from `forked_to_project_id` subquery ...
Diffstat (limited to 'doc/ci')
-rw-r--r--doc/ci/docker/using_docker_build.md2
-rw-r--r--doc/ci/examples/deployment/README.md86
-rw-r--r--doc/ci/triggers/README.md24
-rw-r--r--doc/ci/triggers/img/triggers_page.pngbin5116 -> 110560 bytes
-rw-r--r--doc/ci/variables/README.md2
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.
![Triggers page overview](img/triggers_page.png)
+## 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
index 8ebf68d0384..eafd8519a23 100644
--- a/doc/ci/triggers/img/triggers_page.png
+++ b/doc/ci/triggers/img/triggers_page.png
Binary files differ
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"