Closing a PR should not close linked issues

[lidiaparrilla]

Context

This issue serves as an urgent follow-up to the discussion initiated here: GitHub Community Discussion #23476. Despite considerable community support, there has been no official response for three years. The lack of attention may be attributed to the discussion being marked as answered by @AndreaGriffiths11.

Current Behaviour

1. Pull Request (PR) is created.
2. PR is linked to an issue via any of the linking keywords.
3. PR is merged.
4. Issue is automatically closed.

Rationale for Reconsideration

The current behaviour is incongruent with the workflows of numerous development teams for several reasons:

• Development workflows often include post-merge steps such as deployment and testing.
• A single issue may require multiple PRs, each addressing discrete tasks.
• Issues may span multiple projects, particularly in microservices architectures.

Inadequacy of Suggested Workarounds

Previous discussions proposed linking the PR to the issue without using specific linking keywords. This approach, however, fails to display the PR in a GitHub Project card, negating the benefits of linking.

Proposed Alternatives

The issue can be addressed through multiple avenues:

• Introduce settings to opt-in for the current auto-closure behaviour. By default, issues should not be auto-closed.
• Implement specific keywords to trigger auto-closure, akin to GitLab's approach, e.g., 'closes'.

Community Sentiment

The following comments and discussions underscore the urgency and support for revisiting this issue:

We urge the GitHub team to address this issue promptly to align the platform's functionality with the diverse needs of the development community.

Disclaimer: Yes, ChatGPT wrote this.

[julian-smith-artifex-com]

Adding myself to this. I would also like to be able to disable auto-closing of issues.

I work on PyMuPDF, and we do not want an issue to be marked as fixed until a release has been made that contains the fix. This avoids confusion for users, and simplifies our release process.

Projects differ in how they want to handle things like this, so i find it surprising that Github is forcing the same behaviour on all projects, regardless of size or organisation.

I don't personally mind what the default behaviour is, but it really needs to be configurable.

[ishields]

I agree this is an important thing for teams. The ability to link a PR without auto-closing it would be a great addition and something our team would definitely find very useful. Not every PR solves an issue completely - perhaps there is QA to do, perhaps there are manual steps, etc. There are many cases I can think of where the issue shouldn't be closed immediately and this should be the only option.

link to #issue number or related to #issue number

[JSoet]

Just throwing another comment in for support of this, I can't believe that GitHub is so prescriptive with this, expecting that everyone wants to close a linked issue as soon as they close a PR... Please just give us the option to turn off the automatic closing!

[bitdivine]

Technically no response from GitHub is a kind of response.

[lidiaparrilla]

In which world?

[bitdivine]

It's a quiet no.

On the upside: I heard rumours that GitHub is working on making triggers programmable with something like GitHub actions. If that is true then checkboxes become irrelevant because we can program up whatever behaviour we want.

[bitdivine]

If it is something like that, it would be nice if GitHub were to say so.

[ygavenchuk]

One more use case, when merging a PR shouldn't close the issue. To resolve some issues, from time to time I need more than one PR (usually in different repositories). So it's "slightly" inconvenient to reopen the issue each time a linked PR is merged.

[jamesicon]

+1 to this feature request

[ericpyle]

My use-case is that we have a Review/Test column in our kanban which comes before our Done column. Even though an issue may be fixed and deployed (to dev server) from a developer perspective, it may not be finished from a testing perspective.

While I could avoid linking them, often the developers include screenshots and context in the PR that is not in the original issue, and it's nice to be able to allow testers to see that context for their testing.

[lidiaparrilla]

The behavior seems to have recently worsened. I am getting issues closed even if I don't link them to the PR, just because my commit format includes the issue identifier to trace the commits in the main branch after merge and squash.

[pbiology]

Agreed, this would be great. We have fairly large user stories which require multiple PRs, and having them be linked but not closed would be awesome. Also having a magic word would require less manual work which might be missed.

[mstojanovic8]

We have a Quality Assurance (QA) team that reports bugs via issues on GitHub projects. Whenever a bug is identified, the QA team creates an issue and the developers later link the issue with their relevant Pull Requests (PRs). After the PRs are merged, the issue is closed. However, the QA team still needs to retest the solution. In this scenario, we would like to configure the issues to remain open even after the linked PRs are merged. This would enable the QA team to retest the solution with ease.

Thank you in advance!

[ttaylor29]

@mstojanovic8 agree, we I need this as well!

[filip-komarzyniec]

I don't see anyone highlighting the need for creating this change also for Github Enterprise Server, so I'll add that from me :)

[JSoet]

I thought that all changes which made it into the public version of Github then were pushed into the next release of Github Enterprise? But in general, it's true, this restriction is even more surprising given that there are paying customers who are forced to workaround GH's ideas around process, that issues should be automatically closed when a PR is merged...

[olivier-gosselin]

Looking forward to getting this addressed in a better, more elegant way.

[afterburn]

+1

It's like a car with an automatic parking feature. Convenient for fitting into easy spots without effort, but in some situations, you might prefer to control the parking manually to ensure it's done according to specific needs or constraints.

Please make this an option, I dont really care what the default is as long as I can change it.

[NagyDonat]

Also note that the keyword recognition is somewhat dumb and can be triggered accidentally. For example this trivial NFC commit closed an issue because I accidentally used the word "fix".

Moreover, the after I reopened it the PR was closed again when the same commit was pushed to a private copy of the repository. This is outright buggy behavior in my opinion...

[KindBill]

Please make this an option to auto-close an issue when a PR is merged. +1 to a previous post on making auto-close off by default and providing the option to auto-close when a developer links the PR to the issue.

[mathieurousseau]

+1 make auto-close configurable. That's annoying, I want to have my Project item to move the testing when my PR is merged... not close that issue :(

[epasveer]

What's annoying is the lack of response from GitHub.... Sorry, I had to vent a little.

[bitdivine]

The lack of response is a response. They don't care.

[JaKoutny]

+1

[il-as]

I've been looking for a solution on this to no avail..
In the meantime, I got something that doesn’t solve the closing part but solves the project management side of things....
in the github workflow configuration of the project (the three dots top right then workflow), there was a github workflow enabled that moved the closed issues to the closed column automatically, by disabling this you at least get your issue to not move from where it is..
Doesn't solve everything as it kinda just inverts the problem (now all issues have to be moved to close by hand) but at least we won't be losing track of what we do as a team.

Kinda far from the original problem but I though I'd comment this here in case someone lands here the same way I did and learns from it.

[ericpyle]

I've stopped linking my issues unless I really want the current behavior (which is almost never).

What I think Github devs could do, which may be a more in the "low hanging fruit" category, is to summarize (on the right) which pull-requests have cited this issue (and vice-versa: which issues a pull request cites). Wouldn't address all use-cases, but it would help testers easily access the context they need from those other issues/PRs rather than searching through the conversation history.

[DirkLachowski]

We have now sort of solved this problem by just not using GitHub issues / projects anymore but moved to Jira. Much better experience overall and not looking back. And a great GitHub integration in Jira including PRs, commits, build status, and deployments. Notice the closed/merged PR but the issue is still "In Progress". Can be that easy.

Not really an option for open source projects, but if you have private repos, give it a try. Maybe this is just GitHub realizing that company customers will at some point use Jira anyway and oss projects don't really have a choice - so they're just ignoring the problem because there's nothing to win, even if they fix it. I mean, 4 years later and not even a switch to disable the default action. It can't be that difficult.

[epasveer]

Glad it works for you.

However, not a solution for most of us. :(

[ryu1]

+1