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.
Award Emoji
This it first iteration of award emoji feature.
We have plan to extend emoji picker by the next release.
For now, you can add award by clicking to the emoji picker or posting a regular comment with emoji like "👍" and any other. You can post not only emoji that listed in the emoji picker.
See merge request !1825
Commits without .gitlab-ci.yml are marked as skipped
- Commits without .gitlab-ci.yml are marked as skipped
- Save detailed error when YAML syntax
This also fixes: #3521#3546
/cc @jacobvosmaer
See merge request !1827
Commits without .gitlab-ci.yml are marked as skipped
- Commits without .gitlab-ci.yml are marked as skipped
- Save detailed error when YAML syntax
This also fixes: #3521#3546
/cc @jacobvosmaer
See merge request !1827
Add option to mirror an upstream repository.
Closes internal https://dev.gitlab.org/gitlab/gitlab-ee/issues/279
Depends on gitlab-org/gitlab-shell!29
To do:
- [x] Decide on what user should be the author of the activity feed events. The initial project creator perhaps? That makes sense for personal projects, but less so for group projects, where it's even possible that the creator has since left the team.
- [x] Write specs!
- [x] Write documentation
- [x] Port back relevant commits to CE: gitlab-org/gitlab-ce!1822
----
## Mirror status on project homepage
## Settings navigation item
## Mirroring settings
## Activity feed with new "pushes" (mirror updates)
I have yet to decide on what user should be the author of these events. The initial project creator perhaps? That makes sense for personal projects, but less so for group projects, where it's even possible that the creator has since left the team.
## Warning that branch has diverged from upstream
## Commits heading after failed update
Link send user to the mirroring settings if they are a project admin.
## Mirroring settings after failed update
## New project page
## Import form after failed import
(Screenshot outdated)
Shown when the initial import of a project fails, not when an update of an existing project fails.
cc @dzaporozhets @sytses @JobV
See merge request !51
Fix bug where manually merged branches in a MR would end up with an empty diff
This bug manifested in 8.1 with the refactoring of `RefreshService`. Here's what happens:
1. User create a new branch `foo`.
2. User creates a merge request for `foo`.
3. User merges `foo` into `master` by hand.
4. `RefreshService` reloads the merge request. Since `master` is equivalent to `foo`, this results in an empty diff.
5. `RefreshService` then closes the MR.
This wasn't an issue when you use the normal "Accept Merge Request" flow because the act of clicking the button closes the merge request, so step 4 never happens.
Closes#3314
See merge request !1758
Improve JIRA issue closing
- Zendesk ticket: https://gitlab.zendesk.com/agent/tickets/11034
### Expected behavior
When a merge request has 'Fixes JIRA-1234' in the description the issue should not only be transitioned but also record a comment (regardless of workflow type in JIRA).
### Observed behavior
Depending on the configured workflow a comment may or may not be allowed while transitioning to a new state. In my testing the newest JIRA default workflow did not allow comments while transitioning to 'Done', for example. The 'classic' workflow does, though.
This merge request splits the transition and comment in to two API calls. The advantage is that the comment will be recorded 100% of the time instead of it being dependent on the workflow configuration.
Also, JIRA returns a '204' response code when the transition is successful. I added '204' to the success conditional because we were generating an error in the current configuration even though the transition was successful.
See merge request !45
If a branch is deleted with an open merge request, amended offline, and then pushed again,
GitLab doesn't bother to update the merge request even though the last commit ID and/or
code may have changed. This MR ensures that each push will update any relevant merge
requests and adds a system note if this happens as well.
Closes#2926
Valery Sizov
Valery Sizov
Robert Schilling
Rubén Dávila
Dmitriy Zaporozhets
Ruben DavilaandRubén Dávila
Kamil TrzcińskiandRobert Speicher
Douwe MaanandRobert Speicher
Robert SpeicherandRobert Speicher
adamliesko
Stan Hu
Drew Blessing
Alex Lossent
Jacob Vosmaer