Dropdown bug fixes
- Added back upcoming to milestone filter
- Fixed bug that would cause the currently selected value to disappear on filters
- Fixed bug that throw an error when filtering by upcoming when there is only a milestone in the past
Closes#14536
See merge request !3368
Add links to CI setup documentation from project settings and builds pages
For #14483
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
See merge request !3384
Fix sorting issues/mrs by votes on the groups page
Closes#14394
The `non_archived` scope applied here https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/controllers/concerns/issues_action.rb#L5 overrides the previous `ORDER BY` applied inside the IssuesFinder, with the default scope of the Project model, resulting in SQL errors.
```ruby
Issue.reorder(created_at: :desc).joins(:project).to_sql
=> "SELECT issues.*
FROM issues INNER JOIN projects ON projects.id = issues.project_id
ORDER BY issues.created_at DESC"
Issue.reorder(created_at: :desc).joins(:project).merge(Project.non_archived).to_sql
=> "SELECT issues.*
FROM issues INNER JOIN projects ON projects.id = issues.project_id
WHERE projects.archived = 'f'
ORDER BY projects.id DESC"
Issue.reorder(created_at: :desc).joins(:project).merge(Project.non_archived.only(:where)).to_sql
=> "SELECT issues.*
FROM issues INNER JOIN projects ON projects.id = issues.project_id
WHERE projects.archived = 'f'
ORDER BY issues.created_at DESC"
```
/cc @yorickpeterse
See merge request !3333
Reload the schema before restoring a database backup
If a user tries to downgrade and restore after a failed upgrade,
the database may still contain newer tables. Reload the older
schema before restoring the database to avoid future upgrade
problems. Also, add a rake task to help users add migration
versions to the database so it's easier to recover from these
errors if they do occur. Fixes#13419
See merge request !2807
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
Rémy Coutable
Robert Speicher
Robert Speicher
Phil Hughes
Douwe Maan
Grzegorz Bizon
Abhi Rao
Dmitriy Zaporozhets
Zeger-Jan van de Weg
Stan Hu
Jacob Schatz
Alfredo SumaranandJacob Schatz
Elias Werberich
Mariusz Jachimowicz
Douglas Barbosa Alexandre
Kamil TrzcinskiandRémy Coutable
Drew Blessing
Douwe Maan