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
Follow the CSS Style Guide rules for using shorthand where possible.
Fixes violations of the Shorthand rule. All of these were done manually and I reviewed each change to verify, so they should all be right.
Discussed in #14299.
cc: @jschatz1
See merge request !3313
Soft delete issuables
Fixes#2489
What still needs to happen: research on the indexes, the gem suggests a [lot of changes](https://github.com/rubysherpas/paranoia#about-indexes) though this is probably a good idea to discuss and I'm unsure on the impact of an omnibus upgrade as I suspect creating about 10 new indexes has a large impact on the downtime.
TODO:
- [x] Also group owners can ***soft*** delete
- [x] Button should be hidden
See merge request !2982
Improve performance of viewing individual issues
This MR does two things:
1. `Issue#related_branches` no longer performs Git operations that aren't needed
2. The output of `Repository#exists?` is now cached and flushed properly
Combined these two changes should further cut down the amount of Git operations performed when viewing individual issues (and possibly other pages).
See merge request !3296
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
Use gitlab-workhorse 0.7.1
A small extra defense against interrupted git raw responses. Nice to
have in 8.6 because we introduce /raw/ caching; it would be
unfortunate if incorrect (truncated) responses got cached.
See merge request !3330
These tests would check if the "This project is empty" banner would
contain SSH clone URLs. Oddly enough this should have never passed (as
far as I can tell) as SSH clone URLs in this banner are _only_ displayed
if the current user has at least 1 SSH key attached. Since the tests
never seem to create any they never should have passed, yet somehow they
did. To solve this the Spinach tests in question now ensure at least 1
SSH key is present.
Upgrade Rubocop from 0.35.1 to 0.38.0
See [Rubocop's Releases page](https://github.com/bbatsov/rubocop/releases) for more info on what changed.
Descriptions/StyleGuides removed as discussed in #14233.
Changes:
- Enable DisplayCopNames for lint output.
- Default behavior for `Alias` changed, set to enforce `prefer_alias_method`.
- Enabling Rails cops changed to new syntax.
- Remove StyleGuides and move Descriptions to comments.
- Add missing cops.
- Add TODOs for cops that should be enabled in the future.
- Set TargetRubyVersion to 2.1.
See merge request !3197
Discussed in #14233.
See [their releases](https://github.com/bbatsov/rubocop/releases) for
more info.
Changes:
- Enable DisplayCopNames for lint output.
- Default behavior for `Alias` changed, set to enforce `prefer_alias_method`.
- Enabling Rails cops changed to new syntax.
- Remove StyleGuides and move Descriptions to comments.
- Add missing cops.
- Add TODOs for cops that should be enabled in the future.
- Set TargetRubyVersion to 2.1.
Make HTTP(s) label consistent on clone bar
Sites that use http:// for the external_url should always display HTTP on
the clone bar. Similarly, sites that use https:// should show HTTPS.
Currently, the inconsistency looks like:
Also restores the tooltips that vanished in 7ba4482fcf:
See merge request !3319
Kamil Trzciński
Robert Speicher
Rubén Dávila
Douwe Maan
Felipe Artur
Jacob Schatz
Douwe Maan
Zeger-Jan van de Weg
Robert Schilling
James Lopez
Rémy Coutable
Dmitriy Zaporozhets
Grzegorz Bizon
Jacob Vosmaer
Yorick Peterse
Phil Hughes
connorshea
Arinde Eniola
Stan Hu