Added cache:key to .gitlab-ci.yml allowing to fine tune the caching
The `cache:key` allows you to define the affinity mask of caching, allowing to have single cache for all jobs, or cache per-job, or per-branch, or any other way you would need:
1. Cache per-build for all branches:
```
cache:
key: "$CI_BUILD_NAME"
untracked: true
```
2. Cache per-branch for all jobs:
```
cache:
key: "$CI_BUILD_REF"
untracked: true
```
/cc @DouweM @grzesiek @axil
See merge request !2436
Added X-GitLab-... headers to emails from CI and Email On Push services
Fixes#2098
This adds the 'X-GitLab-Project', 'X-GitLab-Project-Id' and
'X-GitLab-Project-Path' headers to emails from CI and Email On Push in a way
that it is done currently for merge requests and issues emails.
Additionally, CI emails will have 'X-GitLab-Build-Status' header with either
'fail' or 'success'.
Emails from Email On Push will include 'X-Gitlab-Author' header containing the
username of user who did the push.
See merge request !2159
Let the CI runner know about builds that this build depends on
This allows us to implement artifacts passing: runner will download artifacts from all prior builds. It will happen automatically, and always, as long as artifacts are enabled.
## The changes:
This MR exposes list of prior builds in CI::API::Builds.
**The API response when asking for builds**
```json
{
"id": 48584,
"ref": "0.1.1",
"tag": true,
"sha": "d63117656af6ff57d99e50cc270f854691f335ad",
"status": "success",
"name": "pages",
"token": "9dd60b4f1a439d1765357446c1084c",
"stage": "test",
"project_id": 479,
"project_name": "test",
"commands": "echo commands",
"repo_url": "http://gitlab-ci-token:token@gitlab.example/group/test.git",
"before_sha": "0000000000000000000000000000000000000000",
"allow_git_fetch": false,
"options": {
"image": "docker:image",
"artifacts": {
"paths": [
"public"
]
},
"cache": {
"paths": [
"vendor"
]
}
},
"timeout": 3600,
"variables": [
{
"key": "CI_BUILD_TAG",
"value": "0.1.1",
"public": true
}
],
"dependencies": {
"builds": [
{
"id": 48584,
"ref": "0.1.1",
"tag": true,
"sha": "d63117656af6ff57d99e50cc270f854691f335ad",
"status": "success",
"name": "build",
"token": "9dd60b4f1a439d1765357446c1084c",
"stage": "build",
"project_id": 479,
"project_name": "test",
"artifacts_file": {
"filename": "artifacts.zip",
"size": 0
}
}
]
}
}
```
## How it will work?
**Example:**
```
build:
type: build
script:
- echo TEST > test_file
artifacts:
untracked: true
rspec:
type: test
script:
- test-my-project
staging:
type: deploy
script:
- scp test_file root@server.com:
```
**The flow:**
1. We run `build`. The `build` creates a file `test_file`. This file gets archived and send us build artifacts.
2. We run `rspec`. The `rspec` downloads build artifacts from `build`. Uses the `test_file`.
3. We run `staging`. The `staging` downloads build artifacts from `build` and `rspec`, but since the `rspec` doesn't have build artifacts we skip that build. Deploys the `test_file`.
This partially implements the https://gitlab.com/gitlab-org/gitlab-ce/issues/3423.
In the next release we will introduce option to configure what artifacts are received.
/cc @grzesiek @DouweM @sytse @rspeicher
See merge request !2437
some OAuth providers (kerberos for example) only provide a username and an email, but no name. Therefore
a signup fails because the name is empty. Best guess for the name is
probably the username, therefore use it as name.