Disable automatic Issue Closing Pattern per project
Automatically closing an issue because the commit message and or merge request summary mentions the issue is not a good workflow for me, or I would argue, for any serious project.
This was not a problem for me, because I could disable the feature and remain uneffected by this behavior, but now this is gone, and my project setting which informed gitlab not to do this to my issues, lost. (This is now only configurable by the administrator of a gitlab instance, site-wide).
I can see how this can be practical for the smallest and most simple projects (which I suspect makes for the majority of the user base), but for serious projects I dont think this is at all appropriate.
Just to highlight some reasons why this is undesirable...
Patches and issues are not 1:1
As others have raised in old gitlabhq issue 1170, it is not correct to assume that landing one branch closes an issue; an issue may remain open for some time and a number of related patches may individually address a given issue, before the issue can be closed.
The patch submitter has no business deciding that the issue gets closed
This is just flat out wrong; it's important that commit messages make references to the issues they address, yes; but it's incorrect to have the patch submitter deciding that their patch closes your issue.
Rather (and I see this was also suggested in old gitlabhq issue 1170), it could make sense to present a list of issues that could be closed along with the "Merge" button.
Similar to how currently there is a checkmark in the UI to "remove source branch" or (god forbid) "squash commits".
This would put the responsibility of closing an issue in the correct hands: The hands of the reviewer who decided to merge the submitted branch (and of course manual branch merges performed on the command line would not trigger any undesirable side effects either).
Availability & Testing
- No risks to availability are anticipated.
- No cross-browser testing is required.
- Make sure to run the following test https://gitlab.com/gitlab-org/gitlab/-/blob/master/qa/qa/specs/features/api/2_plan/closes_issue_via_pushing_a_commit_spec.rb#L23 and update it if needed.
- There's no need to run all tests in the
package-and-qa
job, but at least the one mentioned above.
- There's no need to run all tests in the