Prevent issues from being closed by merging linked PRs #17308
Replies: 48 comments 61 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/) |
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.
-
|
If you scrub the commit message it will alter the SHA, making your fork look different from the upstream despite having all the same code. You can reopen the issue. It shouldn't get closed again by the same commit. Interesting report of a strange behavior though. |
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
# return to previous branch and delete the temp branch.
git checkout -
git branch -D fastSquash
# continue with your usual merge. |
Beta Was this translation helpful? Give feedback.
-
|
I want a simpler solution -- please remove this auto-close feature entirely. Assuming intent with very common English words that people would use in a good PR description is, well, assumption. And assuming things is never a very good idea. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not entirely sure whether it was brought here as well, but github will close issues cross different organizations if the user who merged the PR has maintainer access in both. This is completely unexpected, because the repositories are not even under the same org. An example where it happened. A simple toggle to not auto-close when the repo where PR was merged is not the same where the issue is could be really great addition and probably be really simple given that the URL and the check is likely nearly at the same place, given that it uses org settings when doing so, because when I wasn't an org maintainer it was not doing so IIRC. Right now it took me 10 minutes to figure out what happened, since I clearly remembered that the issue was opened. |
Beta Was this translation helpful? Give feedback.
-
|
yipes! Is there any indication GitHub are looking at this at all? |
Beta Was this translation helpful? Give feedback.
-
|
+1 - please do it ASAP, it is really painful to re-open everything and restore issues in the projects |
Beta Was this translation helpful? Give feedback.
-
|
I'm having the problem that the issues are being closed when I do a commit with fix tag, but, this did't happened two weeks ago |
Beta Was this translation helpful? Give feedback.
-
|
I just found out that if you link the issue in PR comment it won't close. Only tagging it in PR title closes the issue. |
Beta Was this translation helpful? Give feedback.
-
|
If you use one of the keywords like Fixes or Resolves, I think it will close, even if it's in a comment. Or maybe only in PR description (the first comment). Example: |
Beta Was this translation helpful? Give feedback.
-
|
I can confirm that will be closed. |
Beta Was this translation helpful? Give feedback.
-
|
Why isn't this "feature" just an Action? They could add it as a default if they have this as a strong opinion. |
Beta Was this translation helpful? Give feedback.
-
|
It makes me wonder if Microsoft uses this tool to manage complex projects. How would they be linking issues to PRs? Eat your own dogfood etc. |
Beta Was this translation helpful? Give feedback.
-
|
This really needs to be resolved soon. Makes linking PRs to issues completely impossible because as soon as you have an issue that is slightly more complex than one PR, you have to keep re-openning it. |
Beta Was this translation helpful? Give feedback.
-
|
Sometimes I like creating different branches on the same issue because of some reasons. Merging one should NOT close the issue. For now I constantly need to reopen it manually and set my project status back to "in progress". |
Beta Was this translation helpful? Give feedback.
-
|
So @monitora-media, we've actually gone the extra length of automating reopening issues which still have a linked open PR. I assume it's not an easy task internally, considering the GH API contains properties like |
Beta Was this translation helpful? Give feedback.
-
|
+1 This is preventing out enterprise from leveraging the care convenient feature of creating branch from issue and working on an issue that may span multiple different repos across our frameworks. We also have automation that generates summary audit of an issue once closed so close/reopen is just annoying and we may need to refactor any automation we have for closing. Please make it a priority to fix this asap. Thank you! :) |
Beta Was this translation helpful? Give feedback.
-
|
Not being able to configure this yet is embarrassing. There must be a more appropriate channel of communication since I don't see any official response regarding the status of this issue. Is there another area where someone has at least acknowledged that this has been triaged or looked into? |
Beta Was this translation helpful? Give feedback.
-
|
It does seem like GitHub has stopped developing any feature not related to Copilot. |
Beta Was this translation helpful? Give feedback.
-
this is frustrating tho!! |
Beta Was this translation helpful? Give feedback.
-
|
Totally agree. |
Beta Was this translation helpful? Give feedback.
-
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.
All reactions