Prevent issues from being closed by merging linked PRs

[dougbreaux]

Manually copied over from https://git.luolix.topmunity/t/feature-request-prevent-issues-from-being-closed-by-merging-linked-prs/3255 (where https://github.com/akshaymankar was the original requester).

I really like how the linked PRs in an issue are listed nicely on the project board as well as in the right side of the issue. It really makes discovering PRs from issues easy.

In my current project, we don’t close issues until they reach production. Also, often we have multiple PRs which fix an issues (in multiple repositories). In such cases I do not want the issue to be autmatically closed, currently I just re-open them. This is not ideal because I could forget to re-open the issue and also this workflow causes a lot of notification noise in my team.

It would be nice if this could somehow be configured, or if there was another keyword (instaed of fixes, closes, etc.) to signify that a PR only partially fixes an issue and the issue and the issue must not be closed auotmatically even after the PR is merged.

[marc-hb]

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: This helps address issue #1234 while still preserving some linking.

cc: @defunkt (https://github.blog/2013-01-22-closing-issues-via-commit-messages/)

[blmatthews]

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.

[xavez]

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.

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/

[spdrcd]

I think this is a Workflow configuration to move stuff along the project pipeline. It's not the same as auto-closing issues when PR's are merged.

The issue is not on projects its on issues linked to pr that are auto closing isn't it?

[spdrcd]

please see this https://user-images.githubusercontent.com/5877494/229602978-a8082519-c038-40d0-9111-c94d47028ff9.mp4

that configuration is on project which most of us have no problem with configuration, we're having problems on issues because that configurations for disabling auto close is not there

[xavez]

The issue is not on projects its on issues linked to pr that are auto closing isn't it?

Correct 👍

[jdstrand]

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, foo/main is the default branch but foo/1.x is also supported. I therefore created another repo name foo-1.x and have dependabot scan on its default branch. The only commits to the foo-1.x repo are git pull --ff-only from the foo/1.x branch of the original repo.

This all worked fine until today where I noticed that someone used closes for a different repo in a commit in the original repo. They realized it wasn't closed so re-opened it. I then merged the commit into the foo-1.x repo, which triggered the auto-close feature in the original repo.

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.

[marc-hb]

This re-opened issue was automatically re-closed... by a fork!!

• [BUG] sof_ri_info.py fails on Intel MTL+ binaries thesofproject/sof#8073 (comment)

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.

[mctaylorpants]

I would love to see this as well. I often use Related: #123 to avoid the magic-word behaviour, but as others have mentioned it doesn't get "linked" to the issue so it won't show up in project cards.

[vivekkhurana]

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)

[ihasdapie]

+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.

[steverep]

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:

Successfully merging a pull request may close this issue.

And in the pull request it says:

...linked an issue X days ago that may be closed by this pull request

The operative word there is "may", which certainly does not mean it should automatically close it by default.

[xavez]

The operative word there is "may", which certainly does not mean it should automatically close it by default.

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.

[waynemsmith]

The model Github is perplexingly enforcing does not fit well with trunk based development. I hope they take another look and make it happen.

[oleg-andreyev]

Having multiple PRs and closing one does not mean issue can be closed.

[spdrcd]

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

[alper]

We often have multiple PRs for a single issue and it's beyond frustrating to have to reopen the issue every time.

[pehoracek]

@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.

[JakeTompkins]

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

[ckcr4lyf]

GitHub devs, if the magic word stuff etc, is too complex, maybe just a repository level setting "Disable auto-close issues" , which can be false by default (backward compatible).

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?

[abbluiz-userh]

I'd like to see that option too

Another option is don't automatically close the issue if the target branch is not main even if they are linked

[ADTC]

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.

[jdshkolnik]

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.

[ohjimijimijimi]

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.

[ychin]

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.

[ADTC]

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.

[ychin]

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 scrub scan through hundreds of commits and cross-reference issue numbers all the time.

[ADTC]

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.

[ychin]

Is your repo public

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.

[ADTC]

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.

[ryu1]

+1

[kchibisov]

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.

alacritty/alacritty#8046

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.

[gfranxman]

yipes! Is there any indication GitHub are looking at this at all?

[motyc]

+1 - please do it ASAP, it is really painful to re-open everything and restore issues in the projects

[make-ing]

+1

[stariluz]

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

[pehoracek]

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.

[ADTC]

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: Fixes #123

[kkatusic]

I can confirm that will be closed.

[AndyPook]

Why isn't this "feature" just an Action?
Isn't implementing this kind of behaviour exactly the reason why Actions were invented? (not just build, test, deploy)

They could add it as a default if they have this as a strong opinion.
If I don't want this behaviour, I just remove the Action.

[intotecho]

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.

[Andre-Medina]

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.

[Denny-g6labs]

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".

[stovmascript]

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 PullRequest.closingIssuesReferences and Issue.closedByPullRequestsReferences, implying the inherent behaviour of closing stuff, but it would be great if this was configurable like many have mentioned in this and other discussions.

[HerrCai0907]

+1

[htekdev]

+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! :)

[colinblaise]

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?

[stianjensen]

It does seem like GitHub has stopped developing any feature not related to Copilot.

[spdrcd]

It does seem like GitHub has stopped developing any feature not related to Copilot.

this is frustrating tho!!

[FrancescoBonizzi]

Totally agree.

[jarpoole]

@rileybroughten @azenMatt @evi-liu it would be swell if one of you could help this ticket find its way to the right PM internally!

[azenMatt]

We are the right group, it's on our priority list once we are able to GA the changes in https://github.blog/changelog/2024-10-01-evolving-github-issues-public-beta/ (alongside dependencies and cross-repo milestones)

[spdrcd]

We are the right group, it's on our priority list once we are able to GA the changes in https://github.blog/changelog/2024-10-01-evolving-github-issues-public-beta/ (alongside dependencies and cross-repo milestones)

Awesome!! this is catching up

[colinblaise]

Thank you for the update!