Prevent issues from being closed by merging linked PRs #17308
-
|
Manually copied over from https://github.community/t/feature-request-prevent-issues-from-being-closed-by-merging-linked-prs/3255 (where https://github.com/akshaymankar was the original requester).
|
Beta Was this translation helpful? Give feedback.
Replies: 64 comments 110 replies
-
|
Assuming an issue is automatically fixed because a single merged PR mentions it seems very naive - and indeed dangerous. Validation does not stop after merging. A simple workaround is to avoid the "magic words / syntax", for instance this should avoid the problem: cc: @defunkt (https://github.blog/2013-01-22-closing-issues-via-commit-messages/) Duplicates:
|
Beta Was this translation helpful? Give feedback.
-
|
Where is that? I can’t find how to get there on either my company’s github account or my personal one so am missing something. |
Beta Was this translation helpful? Give feedback.
-
It will not help you to solve this problem, but these are workflows that live inside projects. You can find it in http://github.com/orgs/{orgName}/projects/ |
Beta Was this translation helpful? Give feedback.
-
The issue is not on |
Beta Was this translation helpful? Give feedback.
-
that configuration is on |
Beta Was this translation helpful? Give feedback.
-
Correct 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to see 'disable auto-close' configurable for the repo and/or 'disable auto-close for different repos'. I encountered this issue because I'm working around a limitation in dependabot where dependabot only scans the default branch. I have a project where two branches are supported, but code has diverged. Eg, This all worked fine until today where I noticed that someone used Having more flexibility with dependabot (eg, allow selecting multiple branches, not just the default one) would address this for the above use case, but I'm mentioning it because it seems like cherrypicking and forks could be affected in the general case. |
Beta Was this translation helpful? Give feedback.
-
|
This re-opened issue was automatically re-closed... by a fork!! This feature is train wreck, it's basically an advertisement for JIRA. There should at the very least be a way to turn it off. |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see this as well. I often use |
Beta Was this translation helpful? Give feedback.
-
|
This should be treated on high priority. It breaks lot of workflows and not using magic keywords prevents issue from showing up in tracker. One should be able to switch off auto closing of the issue. I guess every large organisation has a QA team that verifies the issue and then closes it (even after merging pull request, regression test has to be executed) |
Beta Was this translation helpful? Give feedback.
-
|
+1. Sometimes I will have a meta-ticket requiring changes in multiple repos and it is frustrating not being able to use the typical workflow of linking the pull requests to issues. I think that a good way to improve this behaviour would be to require all of the linked pull requests must be merged for the issue to be resolved. |
Beta Was this translation helpful? Give feedback.
-
|
I consider this to be a bug just as much as a feature request. On an issue page in the meta data section it says:
And in the pull request it says:
The operative word there is "may", which certainly does not mean it should automatically close it by default. |
Beta Was this translation helpful? Give feedback.
-
I agree with this. While I understand why it says may it seems to indicate that there is a way to configure this behaviour. Unfortunately it seems there is no way to do this. |
Beta Was this translation helpful? Give feedback.
-
|
The model Github is perplexingly enforcing does not fit well with trunk based development. I hope they take another look and make it happen. |
Beta Was this translation helpful? Give feedback.
-
|
Having multiple PRs and closing one does not mean issue can be closed. |
Beta Was this translation helpful? Give feedback.
-
|
yes. I totally agree, there are different issue and different project is different. Feel like there should be a way to have settings for this |
Beta Was this translation helpful? Give feedback.
-
|
We often have multiple PRs for a single issue and it's beyond frustrating to have to reopen the issue every time. |
Beta Was this translation helpful? Give feedback.
-
|
@alper exactly. On a fullstack project we don't deploy feature branch for minor fixes and usually one issue requires multiple PRs. Try linkin the issue in comment not title. But still, some keywords close the issue. |
Beta Was this translation helpful? Give feedback.
-
|
It would be very helpful for us as well. We have projects that span two or three repositories and often need to make changes to all of them in order to implement a feature. More granular control over the interaction between pull requests and issues would really help clean up the workflow and make sure things don't fall through the cracks |
Beta Was this translation helpful? Give feedback.
-
|
GitHub devs, if the magic word stuff etc, is too complex, maybe just a repository level setting "Disable auto-close issues" , which can be Then wherever the logic runs post merging a PR, just also have a boolean check for this repository property, surely it can't be too hard? |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to see that option too Another option is don't automatically close the issue if the target branch is not |
Beta Was this translation helpful? Give feedback.
-
|
At this point, the workarounds are either to unlink the issues, merge the PR and link the issues again, or to re-open the issues after merging PR. The first one is preferred, as the second one may trigger some workflows. But the first one is not easy if the linking was done using commit messages unless you amend the messages and force-push the amends. It's easier if the linking was done via PR description or manual selection in the sidebar. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the current functionality is tragic. We have to reopen every issue and move it back out of done in its related project after the pull request is merged. |
Beta Was this translation helpful? Give feedback.
-
|
I'm inclined to consider this a bug. I can't understand why allow linking multiple PRs to an issue if only one is needed to close it. Having the possibility to configure this behaviour at the repository level makes perfect sense to me. |
Beta Was this translation helpful? Give feedback.
-
|
Kind of related but I maintain a project that is a downstream fork of another one. I just realized that one of my issues was closed because the upstream fork commit used magic word to close an issue and unfortunately that number matched an unrelated open issue in my repo and closed it as well. This automatic non-configurable setting virtually makes a downstream fork's life difficult because now I'm paranoid how many times that has happened and whether I need to scrub the commit messages every time I merge form upstream. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that's what I meant. Probably bad choice of words there. But no I definitely do not want to alter the commit hashes, so yeah I will just have to scan for issues. I'm still debating whether I should just sort issues by most recently updated after a merge and just see if I have any "updated within last 5 minutes" issues and go re-open them as a quick hack. I don't want to |
Beta Was this translation helpful? Give feedback.
-
|
Yes you can sort issues by "Recently updated" in the Closed list and that should show what was closed recently. You can bookmark the filtered page for quick access. Too bad you can't save the sorting option as default yet. (#16154) Is your repo public? I'm curious how this ends up being a big problem for you. Most forks don't track issues of their own. |
Beta Was this translation helpful? Give feedback.
-
Sure, it's this one: https://github.com/macvim-dev/macvim It adds unique functionality on top of base fork, and therefore exists as its own entity (it's not a GitHub fork so you won't see the officially stamped "forked" entity, but more that the project itself is split from the upstream project). FWIW for the most part this is not a huge issue because the numbers do not line up usually. |
Beta Was this translation helpful? Give feedback.
-
|
Oh cool. Nice tool you have there. The readme is a bit lacking though, as I couldn't know at a glance what the unique functionality is over regular Vim. BTW if you want to quickly check the new commit messages from the upstream before merging, you can try this (and probably automate with a script): # create a temporary branch
git checkout -b fastSquash master
# squash merge the upstream
git merge --squash vim/master
# just add all the merge conflicts. (we're going to throw away this anyway.)
git add --all
# see all the commit messages - make note of any issue mentions.
# close when done and allow the commit. (we're going to throw away this anyway.)
git commit
|
Beta Was this translation helpful? Give feedback.
-
Could you please provide an open-source demonstration of that? This is a potential "attack vector" with possible security implications. Vulnerabilities could be closed without being fixed. Maybe the security aspect could/should help escalate this problem. |
Beta Was this translation helpful? Give feedback.
-
|
I just got an issue auto-closed because I had this in my commit message:
facepalm |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this is a stupid feature. Please fix / provide a way to disable it. |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that Azure DevOps also closes issues(bug or stories) that are
linked to a PR and there is no way to disable it.
Just submitting a PR doesn't even mean the code has been deployed to
testing yet.
The behaviour needs to be configurable based on your workflow and
environment.
…On Thu, 6 Feb 2025 at 22:24, Francois G. ***@***.***> wrote:
Same, this is causing quite some friction for us.
—
Reply to this email directly, view it on GitHub
<#17308 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFBBWGDRQYKJW263GZRYST2ONA7XAVCNFSM5XBFTO6KU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMRQHAYDONRS>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
And with the sunset of |
Beta Was this translation helpful? Give feedback.
-
|
+1 Bump bump bump; this is causing so many problems for my team. |
Beta Was this translation helpful? Give feedback.
-
|
👋 Thank you for all your feedback on this thread! As we work towards a solution, I’d love your input on a few proposed options. Please react to this comment for the option(s) that resonate with you. Bonus points if you indicate in the comments why you selected the option. 🎉 Option 1: Repository-level SettingReact 🎉 to vote for this option. Add a setting in repository settings to control whether merged PRs automatically close linked issues. This would apply at the repo level, meaning either all merged linked PRs close issues in the repo, or none do. 🚀 Option 2: Issue-level Setting (Development sidebar)React 🚀 to vote for this option. Introduce a per-issue setting in the sidebar’s "Development" section, letting you decide whether merged PRs should close the issue. Either all merged linked PRs close the issue, or none do. 👀 Option 3: PR-level Setting (New Keyword)React 👀 to vote for this option. Currently, keywords like This option introduces a new keyword (e.g., Looking forward to hearing your thoughts, and thanks for weighing in! ✨ |
Beta Was this translation helpful? Give feedback.
-
I meant that it wasn't in commit, wasn't there initially, and just someone referenced something else by editing description by the time I hit merge, and it closed issue in completely different org, just because I was maintainer when merging and was maintainer there as well. And got noticed that once user pinged that it's not fixed. |
Beta Was this translation helpful? Give feedback.
-
|
In my opinion option 1 is really the only actual solution to this problem. Options 2 and 3 are interesting options to have, and if you decide to add them later I'm sure some people would find them useful. But only option 1 actually solves the problem. If my process says that issues shouldn't be closed until they're tested, then only a repository level setting lets me enforce that, otherwise I have to police all the PRs that are open to make sure that people are using the right keywords, etc... |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, everyone, for your participation and thoughtful feedback! Based on the results, our team will begin by implementing Option 1 (the repository-level setting) as the first step. We’re also exploring Option 2 and Option 3 for additional flexibility, but our priority is getting Option 1 in place first. I’ll keep you posted as we have updates to share! |
Beta Was this translation helpful? Give feedback.
-
|
Option 1 is great. The two other options feel like busywork that nobody has time to bother with anyway. |
Beta Was this translation helpful? Give feedback.
-
|
The private beta for this is now available 🎉 ! See this thread for how you can get added. |
Beta Was this translation helpful? Give feedback.
-
|
I've voted Option 1: Repo-level Setting as I believe this is the minimum viable solution, and the other options don't fix the harm if option 1 isn't implemented. However, a combination of option 1 plus others could be the best overall. A faster implementation of #1 would be better than a year-long delay to get a more complete fix, too! Workflow problems like this make GitHub Issues really difficult to use. |
Beta Was this translation helpful? Give feedback.
-
100%!!! Please implement the repository level setting and if you later do more then that's great too... |
Beta Was this translation helpful? Give feedback.
-
|
Also, remember that https://en.wikipedia.org/wiki/The_squeaky_wheel_gets_the_grease and that the volume of comments is never representative of the more quiet majority. Even votes are a bit biased towards people who care enough to click: you could get a different result if every user was forced to vote. To be fair, if you can't even spend 5-10 seconds clicking to vote then maybe your opinion does not deserve to count :-D |
Beta Was this translation helpful? Give feedback.
-
|
Glad to see some action finally happening here. I'm struggling to understand the preference for the first options in this discussion. Option 3 is really the limiting factor, and seems the easiest to fix:
As for the other options, it is of course an important feature. I don't mind if auto-closing is configured at repo, organisation or issue level. The only thing I think is important is that it is an opt-in feature and not enabled by default. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
I think that you are misunderstanding the options... The option that you want is option 1 - to implement an option to turn off the auto closing... Option 3 is introducing a NEW keyword, which will not close the associated issue, but any of the existing ways of linking would continue to close the issue ... So as mentioned above, the existing behaviour would continue, and it would not become an "opt in" feature, it would be required that people change their workflow to only use the new keywords, otherwise the issues will continue to be closed as they are now....
(as an aside, my main problem is the use of the current "fixes #x", to close an issue - it is very common for a developer to say that an issue fixes something without actually wanting to close the issue - if option 3 is implemented, I would also recommend to stop "fixes #x" from closing an issue) |
Beta Was this translation helpful? Give feedback.
-
|
@JSoet you are right, I missed that detail. Then what I'm asking for is a non-existent option I guess: Disable existing auto-close for all keywords, except for specific ones (e.g., closes #x). Then making this configurable at issue-repo-organisation level is a future nice-to-have, but it would stop the offending behaviour. |
Beta Was this translation helpful? Give feedback.
-
|
Very glad to see this finally being addressed. The only solution that i'm interested in is number 1. There has to be a way to set the behaviour for all issues and PRs. Is 2 and 3 are provided, they need to be overriden by 1 when set - i do not want it to be possible to create issues or PRs that break how we have decided things should work in our project. |
Beta Was this translation helpful? Give feedback.
-
|
Agree, if option 2 or 3 are implemented they can't override the repo level setting! |
Beta Was this translation helpful? Give feedback.
-
|
This needs to be fixed soon. |
Beta Was this translation helpful? Give feedback.
-
|
Or just let us link closed PRs as well? Work takes many shapes and there's no point in conforming everybody to one imagined workflow. |
|
@bluesprout0612 https://github.com/orgs/community/discussions/17308#discussioncomment-12543144 |
Beta Was this translation helpful? Give feedback.
-
|
Is this not what Actions are for??
This does not have to be complicated.
Just switch off this baked in behaviour.
No need to add extra check boxes for every possible scenario that a world
of devs and organisations desire.
Add a docs page with some Action templates to show how to replicate this
behaviour.
Then every dev/org can set up whatever policy they can dream of.
(maybe, for back compat, it's disabled if you have an action of some
specified name or pattern. This is you opting out/replacing)
…On Mon, 24 Mar 2025 at 10:25, Martin Šťovíček ***@***.***> wrote:
@bluesprout0612 <https://github.com/bluesprout0612>
#17308 (reply in thread)
—
Reply to this email directly, view it on GitHub
<#17308 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAF6XK6RV4GNFBNVGBTS6RL2V7MQHAVCNFSM5XBFTO6KU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMRWGAYDIMZR>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Actions cannot neatly address that issue as-is as they will conflict with other issue operations. Two points that bother me with the current implementation (and the suggested improvement would address that):
Bottom line, the current situation is painful, even when using Actions. Our current workaround is going via Projects; if an issue is attached to a project, the only way of closing it is to move it to the "Done" status of that project. If an issue gets closed and that issue is not in the "Done" status, it will be re-opened by an action (with a comment explaining why). So thanks for the current move and can't wait to see option 1/ implemented 👍 |
Beta Was this translation helpful? Give feedback.
-
🚀 Private beta availableWe're kicking off a private beta for Option 1 from the poll: a repository-level setting to control whether merged PRs automatically close linked issues. If you'd like to join the beta and share feedback, please comment your organization and repository name in this thread (e.g. |
Beta Was this translation helpful? Give feedback.
-
|
Could you please add |
Beta Was this translation helpful? Give feedback.
-
|
@evi-liu - this works great for us and our workflow thank you very much. |
Beta Was this translation helpful? Give feedback.
-
|
Can you please add to Enbridge-Core/devops-enablement-docs |
Beta Was this translation helpful? Give feedback.
-
|
Please add |
Beta Was this translation helpful? Give feedback.
-
|
Can you add
As well? :) |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
|
@evi-liu This does not fit our use case entirely! We have a There is a workflow called I guess we could use option 1 to disable PR’s closing Issues by accident, so would still be good to be in the beta. Can |
Beta Was this translation helpful? Give feedback.
-
|
Users can now choose whether merging linked pull requests automatically closes the issue--check out the announcement! |
Beta Was this translation helpful? Give feedback.
Users can now choose whether merging linked pull requests automatically closes the issue--check out the announcement!