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.

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 https://github.com/orgs/{orgName}/projects/

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?

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

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

Correct 👍

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.

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.

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

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

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

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.

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.

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.

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.

How can I prevent upstream commits with issue-closing keywords from incorrectly closing unrelated issues in a downstream fork?

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.

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

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!

Option 1 is great. The two other options feel like busywork that nobody has time to bother with anyway.

The private beta for this is now available 🎉 ! See this thread for how you can get added.

Amazing that option 1 has been implemented! As the others have said this at least makes Github issues usable. However, for keywords to make sense at all then I think option 3 is also a must.

A faster implementation of #1 would be better than a year-long delay to get a more complete fix, too!

100%!!! Please implement the repository level setting and if you later do more then that's great too...

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

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:
It's way easier to for an admin to check a box than to convince the entire organization to change their workflow around how to write a commit message.

they just need to change their workflow from putting a simple "#X" or "fixes #X " to e.g. "closes #x"
This is not as simple as you make it look like :)
Some organizations have standards and documents that describe exactly what a commit must contain in its message. Changing those standards and documents, and training the engineers to adopt it may mean one entire year of work or more (think government agencies, for example).

Mentioning an issue in a PR is a normal thing, and should not be taken as an instruction to close it.
Exactly the reason why a checkbox is more intuitive and a better design overall. Even if it needs a specific keyword or format, a new engineer may use it by mistake and break the whole thing.

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
Mentioning an issue in a PR is a normal thing, and should not be taken as an instruction to close it.
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.

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

Currently, keywords like Closes #X or Fixes #X automatically close issues when a linked PR is merged.

This option introduces a new keyword (e.g., Links #X or Part of #X) that still links a PR to an issue but prevents automatic closure upon merging. This would allow control at the PR level, but you would have to remember the specific keywords.

(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)

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

Completely agree with @lidiaparrilla. I don't think any of these option complete this discussion on their own, it needs to be a combination of these. I think the combination that works best is option 1 and 3. Is there any plans for implementing option 3?

Agree, if option 2 or 3 are implemented they can't override the repo level setting!

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

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

• You cannot currently prevent the close event from happening. Actions are triggered after the event, so the issue will have to be reopened. This operation will show up in the issue timeline (which can make for a confusing timeline since it might not always be obvious why an issue is re-opened by a bot).
• The event closing an issue attached to a PR is triggered by the user merging the PR, and I couldn't find a way to differentiate the closing of that issue from closing any other issue being closed by clicking on the close button.

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).
And we often end up closing issues (because that is what makes sense after all) which get re-opened by our action, but that's better for us than having some of the issues, that we need to keep open after a PR merge, end up being closed.

So thanks for the current move and can't wait to see option 1/ implemented 👍

Could you please add nosylos/nosylos as well? Thank you!

@evi-liu - this works great for us and our workflow thank you very much.

Can you please add to Enbridge-Core/devops-enablement-docs

Please add perrystreetsoftware/spaceflight

Can you add

• Pureservice/Pureservice.Mobile
• Pureservice/Pureservice

As well? :)