Previously this class would be given a project ID which was then used to
retrieve the corresponding Project object. However, in all cases the
Project object was already known as it was used to grab the ID to pass
to ProjectSearchResults. By just passing a Project instead we remove the
need for an extra query as well as the need for some other complexity
in this class.
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
Add a `gemojione:sprite` Rake task
This task will generate a standard and Retina sprite of all of the
current Gemojione Emojis, with the accompanying SCSS map.
It will not appear in `rake -T` output, and the dependent gems are not
included in the Gemfile by default, because this task will only be
needed occasionally.
See merge request !3130
This task will generate a standard and Retina sprite of all of the
current Gemojione Emojis, with the accompanying SCSS map.
It will not appear in `rake -T` output, and the dependent gems are not
included in the Gemfile by default, because this task will only be
needed occasionally.
[ci skip]
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
Stan Hu
Douwe Maan
Yorick PeterseandRobert Speicher
Kamil Trzciński
Douglas Barbosa Alexandre
ashleys
Jacob Vosmaer
Dmitriy Zaporozhets
Rémy Coutable
Robert Speicher
Pascal Bach
Iuri de SilvioandRémy Coutable
Peter Suschlik
evuezandRémy Coutable