Close linked issues even when the PR targets a branch that is not the default

[nicole-obrien]

Currently when linking issues to PRs to close, the linked issues only closes if the target branch for the PR is the default branch. I think this currently a flaw and I don't understand the reasoning for this. If, I as a maintainer specify the PR closes the issue, why does it not do that when the PR is merged independent of the target branch.

This is specifically a good time to make that change, now that we have the new development section where we can create branches and they are automatically linked.

[DanSheps]

Just want to add to this to hopefully help the developers with a use case.

We currently have the following 3 main branches in our one repo:

master
develop (our current development branch, where we work on 1.1.x)
feature (our "major" release branch: 1.x.0)

When we are working on features, we do it against the feature branch and close out issues as PR's happen for our milestones. We have to close these issues out manually as develop is our default branch and not feature. It would be handy to have a "secondary 'default' branch" for us to help us handle this case where we do development against 2 different branches simultaneously.

[jsoref]

There are too many flows to have a model where everyone will be happy always.

Some repositories will have branches for multiple concurrent branches. E.g.:

• 1.0.x
• 1.1.y
• 1.2.z
• 2.a
• main

In that model, there could be an issue that is only relevant to 1.2.z and thus when a fix is merged into 1.2.z, the issue should be closed.

It's true, you could also have feature branches in the same repository, and you'll have problems where merging something into a feature branch would close your issue. But, the expected approach from the current workflow is to have an issue for landing the feature into the feature branch, and then a separate tracker for when you land the feature branch into the release branch.

For everything else, you can use "projects".

[DanSheps]

There are too many flows to have a model where everyone will be happy always.

There are branch protection rules, I don't think it is too much to ask for github to do something similar for issues where you can close related issues when the PR is merged, and it could be on a branch by branch basis. Even a "these branches auto-close issues when PR's are merged" would be sufficient. This is a easy win

But, the expected approach from the current workflow is to have an issue for landing the feature into the feature branch, and then a separate tracker for when you land the feature branch into the release branch.

For everything else, you can use "projects".

This is a "feature request discussion" not a "I don't see how this fits my use case so I don't like this" discussion

[Zadjil-AR]

I agree with nicole-obrien and DanSheps.

Using the Git-Flow there are at minimum 2 primary branches (the "Develop" and the "Main", with "Develop" being the normal target of PRs) and when there are critical hotfixes or patch releases on older versions, these issues will be closed as they get released which is before they are brought into "Develop".

The other common situation is where an "Epic" branch is needed to manage larger change, and during the life of that "Epic" there may be issues that apply to that only and are not relevant to the "Develop". Under the current system they would only be automatically closed if they are merged into "Develop".

As to jsoref's point about using Projects, that is what I do to track and manage the change. The management of the projects is made harder as the issues remain open on the project after the PR has been merged and the issue resolved.

If the expectation is that a PR that targets the feature branch does not close the issue until it is in the release branch then the PR that merges the feature branch should inherit the issue. To me that would create a large amount of extra noise, and would not always be relevant. On the plus side it would allow the issue to be tracked all the way to the release branch, which would be beneficial.

---

What I would like to see is an option in the branch protection rules, which would allow it to be marked as a 'closes issues' branch.

If this is not something that is ever going to be on the roadmap, then it would be good to know this so that I know it is something that is worth investing time in creating a Bot to perform the functionality.

[jsoref]

The roadmap is public and goes out more than a year. I think it's unlikely that this feature will be implemented, so if I were you, I'd just write a workflow.

https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions

You can use

on:
  pull_request:
     type: closed
     branches:
     - specific_branches 
if:  github.event.pull_request.merged

This should allow you to write code that closes things when they're merged into specific branches, but not close them if they're merged into other branches.

[spdrcd]

Different projects works differently, I think rather than having that as the default behvaior. There needs to be ways to customize it. For our project there are actually additional manual testing in place, and additional integration before we can close the issue ticket. So automatically closing issue ticket immediately after we merged the any branch is actually not wanted behavior

[JSoet]

There's actually another issue asking for the reverse behaviour, to turn off the closing off issues entirely:
https://github.com/orgs/community/discussions/23476

It actually has a lot more support so I would hope that it is implemented first before this issue.

[DanSheps]

Thanks for sharing that. I feel like if done correctly, tackling one could tackle the other at the same time

[rtibbles]

I agree - just having a protection rule checkbox of "merging to this branch closes linked issues" means that this could be toggled off entirely, or toggled on for specific branches - so I think this kind of optionality should handle both cases.

And just in general, a big thumbs up to this whole idea - a lot of projects have multiple branches for different release series and even when PRs are merged up to the newer branches, the issues don't then get closed, so having it happen at the first merge would be incredibly helpful.

[evan-d-lauer]

PLEASE!!!! just put this in settings somewhere! let me specify a set of branches that count as "main" for this purpose, and performs the exact same actions as if the PR were targeting main