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
Ability to move issue to another project
Tasks:
- [x] Create scaffold of service that will move issue to another project.
- [x] Close old issue, add system note about moving issue to a new project.
- [x] Create a new issue, add system note about issue being moved from old project.
- [x] Check if issue can be moved to another project before executing service
- [x] Check permissions when moving an issue (`:admin_issue` ability)
- [x] Display select box for a new project when editing an issue
- [x] Show only projects that issue can be moved into in that select box
- [x] Add project select handler, helper and some permission filters to it
- [x] Preserve as much information as possible, including author
- [x] Prepare mechanisms that unfolds local references in issue description
- [x] Rewrite issue description with references unfolding and add some specs for it
- [x] Rewrite all system notes and comments attached to issue that is being moved
- [x] Update `Label` so that is was able to create cross reference labels (separate MR)
- [x] Add notifications about moving issue to another project
- [x] Display confirmation alert/message when issue move has been requested
- [x] Make it possible to undo selecting project where issue will be moved to
- [x] Add column to issue, that will indicate if it has been moved to another project
- [x] Do not allow to move issue that has been already moved
- [x] Write top-to-bottom feature spec in RSpec instead of Spinach
UI:
Closes#3024
See merge request !2831
Add label description in tooltip to labels in issue index and sidebar
The tooltip can get quite big, but it’s so useful to inform people about what these labels mean
new
@JobV writes on Slack:
> yeah I think it’s better than not, but I’d have to try it 😃
>
> cautious yes, revert if it’s annoying 😉
See merge request !3124
Show a notice for diffs that are empty/too large
This builds upon https://gitlab.com/gitlab-org/gitlab_git/merge_requests/72 but will fail until said MR has been merged.
Fixes gitlab-org/gitlab-ce#13912, gitlab-org/gitlab-ce#13644, gitlab-org/gitlab-ce#13557, gitlab-org/gitlab-ce#13267, gitlab-org/gitlab-ce#3906
See merge request !3185
Instead of plucking IDs this class now uses ActiveRecord::Relation
objects. Plucking IDs is problematic as searching for projects can lead
to a huge amount of IDs being loaded into memory only to be used as an
argument for another query (instead of just using a sub-query).
Support YAML alias/anchor usage in .gitlab-ci.yml
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 gitlab-org/gitlab-ci#342
See merge request !2958
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>
Add support for cross project references for labels
## Summary
Support for cross project references for labels.
## Rationale
1. Cross project label references are currently not supported in GitLab
1. `to_reference` method signature in `Label` model breaks the abstraction introduced in `Referable`.
`concerns/referable.rb: def to_reference(_from_project = nil)`
Signatures:
```
label.rb: def to_reference(format = :id)
commit_range.rb: def to_reference(from_project = nil)
commit.rb: def to_reference(from_project = nil)
external_issue.rb: def to_reference(_from_project = nil)
group.rb: def to_reference(_from_project = nil)
issue.rb: def to_reference(from_project = nil)
merge_request.rb: def to_reference(from_project = nil)
milestone.rb: def to_reference(from_project = nil)
project.rb: def to_reference(_from_project = nil)
snippet.rb: def to_reference(from_project = nil)
user.rb: def to_reference(_from_project = nil)
```
This MR suggests using `def to_reference(from_project = nil, format: :id)` which makes use of keyword arguments and preserves abstract interface.
1. We need support for cross project label references when we want to move issue to another project
It may happen that issue description, system notes or comments contain reference to label and this reference will be invalid after moving issue to another project and will not be displayed correctly unless we have support for cross project references.
Merge request that needs this feature: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2831
I think that cross project label references may be useful, (example: `Hey, see our issues for CI in GitLab CE! - gitab-org/gitlab-ce~"CI"`).
cc @JobV @DouweM @rspeicher
See merge request !2966
Add a spec for WikiPipeline
Removes the specs from GollumTagsFilter that were more like integration
tests for the pipeline than unit tests of the filter.
See merge request !3054
Additional specs cover a case when one of the builds is running but
allowed to fail. Previous implementation returned `running` status,
which is wrong. This behavior has been changed in 8.5, this commit adds
missing specs.
Fix missing ignored? for GenericCommitStatus
This is pretty important fix. We should not release 8.5 without this.
It critical error when handling GenericCommitStatus:
```
undefined method `ignored?' for #<GenericCommitStatus:0x007fe1a2a20fe0>
```
cc @grzesiek
See merge request !2899
Rémy Coutable
Kamil TrzcińskiandRémy Coutable
Robert SpeicherandRobert Speicher
Douwe MaanandRémy Coutable
Jacob VosmaerandRémy Coutable
Geoffrey Lalonde
Rubén Dávila
Stan Hu
Achilleas Pipinellis
Yorick PeterseandRobert Speicher
Douglas Barbosa Alexandre
Pascal Bach
Iuri de SilvioandRémy Coutable
Grzegorz Bizon