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
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
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
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
External Users
The user has the rights of a public user execpt it can never create a project, group, or team. Also it cant view internal projects.
Partially fix for both #4009 and #13938 (except the LDAP sync or a pattern to detect external users)

See merge request !3171
CSS style guide
Working towards what was discussed in #13552, this adds the [SCSS Linter gem](https://github.com/brigade/scss-lint) for style guide conformity in CI.
TODO:
- [x] Agree on and write SCSS Style Guide Documentation.
- [x] Document the `scss-lint` config file.
- [x] Figure out how best to run this in CI, right now it's taking longer than I would think it should.
- [x] Use CSSComb for auto-correction (Maybe just include a CSSComb config file and have developers run the node package manually if they're interested in using it?).
My logic for not using CSSComb in the first place is that, AFAIK, we don't currently require Node/NPM, even in the dev environment. Maybe I'm wrong about that? `scss-lint` is a Ruby implementation of a similar concept, but it doesn't include autocorrect.
Is there a way we can run get GitLab CI to run `scss-lint` without having to put together the full GitLab application? Seeing as it's just static analysis, it seems like a waste of time/resources.
/cc @jschatz1 @rspeicher
See merge request !3069
Cleanup Ci::Commit, Ci::Build and CommitStatus views
This MR tries to do first sweep of cleanups to Ci::Commit and
Ci::Build objects removing all view-related functions and fixing the
API from other side.
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/6046
See merge request !2760
Bring from EE: Share Project with Group
- [x] Models and migrations
- [x] Logic, UI
- [x] Tests
- [x] Documentation
- [x] Share with group lock
- [x] Api feature
- [x] Api docs
- [x] Api tests
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
For #12831
cc @DouweM @rspeicher @vsizov
See merge request !3186
- Remove all view related methods from Ci::Build and CommitStatus
- Remove unused Ci::Commit and Ci::Build methods
- Use polymorphism to render different types of CommitStatus
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).