feature: delete stale/merged branches

[zramsay]

these can often linger in repos

[bkeepers]

I like it. I was imagining that functionality would belong in a separate app, but as I think more about it, I think it makes sense to be part of stale. Here's a few notes on how I imagine it would work:

• Automatically prune the branch on pull_request.closed (it can easily be reverted from the GitHub UI)
• Prune branches that haven't been pushed to in X days
• Support for a whitelist of branches not to prune (e.g. long-lived branches for beta/stable releases)

[hiimbex]

For the purpose of the current system of defaults in stale, I think that:

Automatically prune the branch on pull_request.closed (it can easily be reverted from the GitHub UI)

should be set to true by default, since it's very easily undone. However, is it worth throwing a check for whether the PR was merged or not? I know I have accidentally closed PRs on my phone before, and there are lots of cases for closing a pr but still using the branch somewhere else.

Prune branches that haven't been pushed to in X days

should be set to either a very high number (90?) or disabled by default.

[zramsay]

Mostly agree with the notes. I would say that automatically pruning branches on merge is fine, however, if a PR is closed a probot comment with grace period would be good because often PRs can be closed and not merged when the work still a WIP and plans to be re-visited. This gives user option to add to whitelist before the branch is automatically deleted.

re: prune branch that haven't been pushed to in X days. Yeah, disabled by default, and "default" days number should even be 6mo-1yr

While we're on the topic, what do folks think of a tool that detects stale repos themselves? I find a lot of open source projects/companies grow the number of repos over time and most of them are completely deprecated after a while.

[ghost]

While we're on the topic, what do folks think of a tool that detects stale repos themselves?

My 2c: I think it is hard to detect stale repos. Repos that have no activity may still be consumed as packages by other projects. It is also not going to save cost as Github charges per user and not per repo.

[stale]

Is this still relevant? If so, please comment with any updates or addition details.

[estahn]

I think this is still relevant.

[samuelmjohnston]

Support for a whitelist of branches not to prune (e.g. long-lived branches for beta/stable releases)

Does github expose the protected branches set up in the repo? I'd like to be able to use that so my configuration on a repo is not split too much.

[BenCoffeed]

Perhaps, you could apply one of the exemptLabels within the branch name for safe-keeping?
fix/bugBasher2867-everFresh

[travi]

I was imagining that functionality would belong in a separate app, but as I think more about it, I think it makes sense to be part of stale.

i can certainly see how this functionality would be useful to existing users of the stale bot, but i could also see this being more separate. i am personally not a stale bot user, but i'd love to have some automated help cleaning up old branches

[gautamarora]

was considering building this app, but looks like its already been done by @SvanBoxel here 🎉

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[estahn]

Yes, it is still relevant.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[imkaka]

Any updates on this? because we should not add another bot just for deleting branches, stale should be able to do it when asked.

[geekdave]

This might not be needed now that GitHub has added the ability to auto-delete feature branches after PR merges: https://help.github.com/en/github/administering-a-repository/managing-the-automatic-deletion-of-branches

Managing the automatic deletion of branches - GitHub Help

You can have head branches automatically deleted after pull requests are merged in your repository.

[peter-dolkens]

This might not be needed now that GitHub has added the ability to auto-delete feature branches after PR merges: https://help.github.com/en/github/administering-a-repository/managing-the-automatic-deletion-of-branches

I'd argue this is more important now - with that feature turned on, stale branches tend to be orphaned/abandoned, or long-lived branches now, as opposed to work that's being actively worked on.

Whitelist your long-lived branches, enable auto-prune of merged branches, and then let stale clean up the abandoned branches.

The ideal workflow for this would be to raise a PR with the name "Pruning [branch]", auto-close it, then delete the branch - this would let users browse closed PRs if they need to get back to a branch which has been pruned.

Managing the automatic deletion of branches - GitHub Help

You can have head branches automatically deleted after pull requests are merged in your repository.

[cdaringe]

what would the interface look like here?

- deleteStaleBranch: true
- daysUntilBranchStale: 60
- exemptStaleBranchMatches:
    - gh-pages
    - "long-running.*"

[iAnomaly]

Wow! Over 4 years later and still no traction here!

This might not be needed now that GitHub has added the ability to auto-delete feature branches after PR merges: https://help.github.com/en/github/administering-a-repository/managing-the-automatic-deletion-of-branches

I'd argue this is more important now - with that feature turned on, stale branches tend to be orphaned/abandoned, or long-lived branches now, as opposed to work that's being actively worked on.

Whitelist your long-lived branches, enable auto-prune of merged branches, and then let stale clean up the abandoned branches.

The ideal workflow for this would be to raise a PR with the name "Pruning [branch]", auto-close it, then delete the branch - this would let users browse closed PRs if they need to get back to a branch which has been pruned.

**Managing the automatic deletion of branches - GitHub Help**You can have head branches automatically deleted after pull requests are merged in your repository.

Agree this is still super important today. As @peter-dolkens points out, there are plenty of edge cases where a PR isn't merged or even opened in the first place but still orphaned branches remain.

I work at a modestly sized organization with roughly 60 engineers and even with GitHub's native automatic deletion of branches after merge, we still have 500+ stale branches on one of our most used repositories. There are many downstream CI/CD systems that maintain history for these branches until they are deleted upstream.

GitHub Docs

Managing the automatic deletion of branches - GitHub Docs

You can have head branches automatically deleted after pull requests are merged in your repository.

[taylorsmithgg]

+1 for this as well, should be reopened.
I have a huge number of orphaned branches w/o PRs I'd love to have stale bot clean up.
These are usually under /branches/stale on the repo.
Our org has several hundred that will never get purged unless we have some automation.

[VicJerUk]

I think people missing the point branches can be created on the fly and not neccessarily branch that you create PR from is the branch you started off with and soon you end up with lots of stale branches in the repository if you work in a larger team.

[simonwalton]

+1 for this. Whilst automatic branch deletion on PR merge is very nice, it doesn't solve the problem of engineers naturally creating many test/experimental branches that just never get merged into mainline. You can't effectively force all engineers in your company to have "Github cleanup" days - automation is the solution. A per-org "maximum unprotected branch age" or similar would be a decent start.