-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(pr): Add cleanup subcommand to delete merged local branches #7322
base: trunk
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking it might be possible to create a separate gh-cleanup
executable for testing this before it was released, but given the changes to shared client.go
& objects.go
I guess that is not possible—the whole gh
binary needs to be replaced. Can try building from sources and using this for a few days.
// Any local branch whose HEAD is a commit of a merged or closed PR is a | ||
// candidate for deletion, because the local branch's history is a prefix of | ||
// the remote branch's history (i.e. there are no local commits that the | ||
// upstream does not have). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 So for a squash- or rebase-merged PR, this logic verifies that the user’s local commits made it into the PR before it was merged, and we trust that the resulting commit to the base branch actually reflected those changes (perhaps with some amendments from the maintainer). Seems close enough. Compare discussion of git branch -d
behavior in #380.
Tried it after jenkinsci/github-checks-plugin#307 was merged, and did not work at all unfortunately: $ git remote -v
fork https://github.com/jglick/github-checks-plugin.git (fetch)
fork https://github.com/jglick/github-checks-plugin.git (push)
origin https://github.com/jenkinsci/github-checks-plugin.git (fetch)
origin https://github.com/jenkinsci/github-checks-plugin.git (push)
$ git branch
bumps
* master
$ gh pr cleanup --all
Loading PRs for 2 local branches with upstreams. This can take a minute if you have many branches...
✓ No branches to be cleaned up!
$ gh pr cleanup 307
The following branches can be cleaned up:
BRANCH STATUS PULL REQUEST
master ! MERGED #307 Standardized & simplified & updated build & test infrastructure
! indicates that a local branch is behind its remote.
? Delete all 1 merged or closed branches? Yes
failed to run git: error: Cannot delete branch 'master' checked out at '…/github-checks-plugin'
|
My repo config at this point: [core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@github.com:jenkinsci/github-checks-plugin.git
fetch = +refs/heads/*:refs/remotes/origin/*
gh-resolved = base
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "fork"]
url = https://github.com/jglick/github-checks-plugin.git
fetch = +refs/heads/*:refs/remotes/fork/*
[gitg]
mainline = refs/heads/master
[branch "bumps"]
remote = fork
merge = refs/heads/bumps |
In another case I tried, |
This is possible, and there are a couple plugins. See for example gh-poi. I decided to hack out this native command because it felt like it should be native to me, and I was hoping to reuse the existing logic around handling default repositories and configuration and stuff.
I haven't tested the behavior of When using cli/pkg/cmd/pr/cleanup/cleanup.go Lines 119 to 123 in 8ce601e
Another possibility is that if your PR was not up-to-date, the current implementation does not look at PRs against upstream repositories: cli/pkg/cmd/pr/cleanup/cleanup.go Line 294 in 8ce601e
That's odd. I wonder if that's because for not-up-to-date PRs, the current implementation looks at the cli/pkg/cmd/pr/cleanup/cleanup.go Line 206 in 8ce601e
I'll take a stab at properly supporting forks if I find the bandwidth, although this is low priority for me because it works for my personal use cases already. I haven't fully worked out what the semantics for forks should be yet (e.g. which PRs to search for, how to find them, and which branches to delete). |
Makes sense; forks are trickier to handle. If you find the time, wonderful, or I might. |
I know your contributing guidelines say to avoid issues labelled
core
, but I hacked this together over the weekend after encountering #380 and it performs pretty well for me, so I thought I'd open a PR in case you folks want to take it over. Notably, this PR is still missing tests.Here's an example of the UI for this subcommand on one of my repositories (note that actual output in TTY is colorized):
Here is the implemented interface:
Fixes #380.