Fix 500 when using CI
- Fix for Ci::Build state machine, allowing to process builds without the project
- Forcefully update builds that didn't want to update with state machine
- Fix saving GitLabCiService as Admin Template
Fixes#3556
See merge request !1873
Generate system note after Task item has been updated on Issue or Merge Request.
Reference: #2296
Everytime the User check or uncheck a Task Item from the Issue or
Merge Request description, a new update is going to be
added to the activity logs of the Issue or Merge Request.
Note that when using the edit form, you can only update the Task item
status or add/delete/modify existing ones. Doing both actions is not
fully supported.
See merge request !1848
- Fix for Ci::Build state machine, allowing to process builds without the project
- Forcefully update builds that didn't want to update with state machine
- Fix saving GitLabCiService as Admin Template
Update copy used in alert message when deleting branches or tags.
Reference: #2993
Before:


After:


See merge request !1846
Add upvote/downvote fields to merge request and note API to preserve compatibility
As discussed in !1825 we should not break the API compatibility.
* This MR adds the fields `upvotes`/`downvotes` to the merge request API again, which always return `0`.
* Add the fields `upvote`/`downvote` to the notes API, which always return `false`
This behavior is documented in the API docs.
See merge request !1867
Make tag API for release feature consistent
Make tags API consistent with other tags methods. This changes the endpoint from `PUT /projects/:id/repository/:tag/release` to `PUT /projects/:id/repository/tags/:tag_name/release`.
On thing the API is still missing, is an error if the tag does not exist. Right now it returns 200 even the tag does not exist. I'll fix that such it returns 404.
@stanhu Can you review?
@rspeicher This MR should go into 8.2
See merge request !1864
Handle removed source projects in MR CI commits
Fixes#3599
@dzaporozhets assigning this to you since you wrote the original code. Perhaps checking for the source project isn't the right way, but I'm not sure if there's a better way (e.g. somewhere earlier in the process) that we can detect this.
See merge request !1859
Port GitLab EE ProjectsFinder changes
These changes were added in GitLab EE commit
d39de0ea91. The tests were a bit bugged
(they used a non existing group, thus not testing a crucial part) which
I only noticed when porting CE changes to EE.
See merge request !1854