delta/gitlab/gitlab-ce.git/spec/lib/ci, branch push-ref gitlab.com: gitlab-org/gitlab-ce.git Test dependencies defined as symbols 2016-03-23T11:55:23+00:00 Kamil Trzcinski ayufan@ayufan.eu 2016-03-22T14:27:55+00:00 858bf727bc4841bf5bbcff7348fd46ea2090e753 






Fix build dependencies, when the dependency is a string
2016-03-23T11:55:23+00:00

Kamil Trzcinski
ayufan@ayufan.eu

2016-03-22T14:25:53+00:00

8fac12c590e808537c447119343f860f269eb67d












Merge branch 'feature-ci-only-except-trigger' into 'master'

2016-03-22T09:42:40+00:00

Kamil Trzciński
ayufan@ayufan.eu

2016-03-22T09:42:40+00:00

fc6ee359287c6bd286e32ce808e7069714e1732e


CI: Add 'triggers' keyword to 'only' and 'except' lists to allow control over when triggers cause builds to run

Currently, the `only` and `except` keywords in `.gitlab-ci.yml` only accept ref names or the special `branches` and `tags` keywords. However, these are primarily useful when controlling how repository activity affects the creation of builds. In my case, instead of building on every commit, I'd like to use the following logic:

- If the repository is tagged, do a build.
- Any other normal commits should not cause a build.
- If a build is triggered via the API, always create one for the specified ref.

From what I can tell, this isn't possible via the existing YAML syntax. In this MR, I introduce a new keyword `triggers` that goes along with `branches` and `tags`. I can implement the logic above using the following job configuration:

```yaml
only:
  - tags
  - triggers
```

I updated the tests and documentation to reflect this and everything seems to pass.

See merge request !3230





CI: Add 'triggers' keyword to 'only' and 'except' lists to allow control over when triggers cause builds to run

Currently, the `only` and `except` keywords in `.gitlab-ci.yml` only accept ref names or the special `branches` and `tags` keywords. However, these are primarily useful when controlling how repository activity affects the creation of builds. In my case, instead of building on every commit, I'd like to use the following logic:

- If the repository is tagged, do a build.
- Any other normal commits should not cause a build.
- If a build is triggered via the API, always create one for the specified ref.

From what I can tell, this isn't possible via the existing YAML syntax. In this MR, I introduce a new keyword `triggers` that goes along with `branches` and `tags`. I can implement the logic above using the following job configuration:

```yaml
only:
  - tags
  - triggers
```

I updated the tests and documentation to reflect this and everything seems to pass.

See merge request !3230






adjusted behavior so canceled builds tagged as allowed to fail do not fail build
2016-03-17T14:55:10+00:00

Geoffrey Lalonde
glalonde@google.com

2016-03-17T14:54:56+00:00

4117c815df73ba80258ca472470735826c68753a












add tests for only/except 'triggers' keyword
2016-03-15T13:35:38+00:00

Jason Roehm
jasonr@3db-labs.com

2016-03-15T13:35:38+00:00

6c1badbd108a12d1217596a3319f9bd3ca7319b8












Merge remote-tracking branch 'origin/master' into gitlab-ci-yaml-updates
2016-03-11T13:22:49+00:00

Kamil Trzcinski
ayufan@ayufan.eu

2016-03-11T13:22:49+00:00

388f69b0de6450ec48a8b88df48bbe2d465593ea

# Conflicts:
#	spec/lib/ci/gitlab_ci_yaml_processor_spec.rb





# Conflicts:
#	spec/lib/ci/gitlab_ci_yaml_processor_spec.rb







Allow to define on which builds the current one depends on
2016-03-11T13:15:13+00:00

Kamil Trzcinski
ayufan@ayufan.eu

2016-03-11T13:15:13+00:00

9a271d80128451eecc9a301d5e9924c09740be07












Allow to pass name of created artifacts archive in `.gitlab-ci.yml`
2016-03-11T12:43:57+00:00

Kamil Trzcinski
ayufan@ayufan.eu

2016-03-11T12:43:57+00:00

d300ecf8d9e886ee7cff9b883bfcdbdb1e49769b












Describe special YAML features: the use of anchors and hidden jobs
2016-03-11T12:41:05+00:00

Kamil Trzcinski
ayufan@ayufan.eu

2016-03-11T12:39:11+00:00

ad4d3a075fc338280baaf6240861c9de7aa312ad












Support YAML alias/anchor usage in .gitlab-ci.yml
2016-03-08T07:49:32+00:00

Pascal Bach
pascal.bach@siemens.com

2016-02-24T14:48:56+00:00

344d6e6f89cceb33e371e10de8262154ee108fbe

This allows to reuse one job as a template for another one:

```
job1: &JOBTMPL
  script: execute-script-for-job

job2: *JOBTMPL

```

This also helps to solve some of the issues in #342

Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Fabio Huser <fabio.huser@siemens.com>





This allows to reuse one job as a template for another one:

```
job1: &JOBTMPL
  script: execute-script-for-job

job2: *JOBTMPL

```

This also helps to solve some of the issues in #342

Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Fabio Huser <fabio.huser@siemens.com>