Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 44,153
    • Issues 44,153
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,436
    • Merge requests 1,436
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #19754
Closed
Open
Created Oct 05, 2017 by Tristan Van Berkom@tristanvb

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.
Edited Feb 18, 2020 by Walmyr Lima e Silva Filho
Assignee
Assign to
Time tracking