Refined-github: After merge, automatically post comment

[fregante]

_Sometimes_ I want to merge and leave a comment after. Should that be handled automatically too?

How about we show more checkboxes when tests are running:

• [ ] wait for tests to pass
  
  
  
  • [ ] automatically post the comment
  
  
  • [x] automatically delete branch (-> #2186)
  
  

Perhaps we can find a more _refined_ UI

More context in

• #865 _(Add auto merge after tests pass button)_
• #908 _(Automatically delete a branch after PR merge)_
• https://github.com/isaacs/github/issues/1121 _(Auto-delete branch on pull request merge)_

---

IssueHunt Summary

fregante has been rewarded.

Backers (Total: $53.97)

• issuehunt ($53.97)

Submitted pull Requests

- #2186 Add pr-branch-auto-delete feature

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
  

  - Need some help from other developers? Add your repositories on IssueHunt to raise funds.

IssueHunt has been backed by the following sponsors. Become a sponsor

[sindresorhus]

automatically delete branch

This one should be checked by default.

[fregante]

I forgot that I had already opened an issue for branch deletion: #908

@hkdobrev brought up a good point though:

However, here's a case where you don't want to delete - e.g. you have a long-running branch like the git-flow

Having it pre-selected is a bit dangerous in those cases.

[sindresorhus]

Having it pre-selected is a bit dangerous in those cases.

Users can just uncheck it then, and you can easily restore deleted branches from the GitHub UI.

[fregante]

Imagine doing that on every PR though. Also this happens when you’re probably not looking at the tab, should you forget to uncheck it, so the branch might stay deleted for a while.

I never use long-lived branches so this doesn’t affect me in the end.

[sindresorhus]

They could disable the feature then. We should optimize for the 95%.

[yakov116]

I would put a one time pop-up so that users don't get upset

[tooomm]

I assume this would only be displayed for PR's that have their corresponding branch in a repo you have write access to?

So if somebody merges a external PR he won't see it?

Otherwise a really great addition!

[fregante]

Yep, the branch deletion would only be useful when merging your own PRs from or PRs from other _collaborators._ However we can't detect the permission so the checkbox will be shown for everyone (+ an info icon to give more info, like in #1072 )

[iwiznia]

automatically delete branch (-> )

👍 on this

[jiang-wei]

automatically delete branch (-> )
^^^^^^^ on this

[endtoend]

If a PR is accidentally deleted it can always be restored. Deleting would be a great benefit to those using trunk-based development; those using long lived branches (like develop) might be able to lock down protected branches.

[fregante]

those using long lived branches (like develop) might be able to lock down protected branches.

@endtoend that's a great point

[IssueHuntBot]

@issuehunt has funded $53.97 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[fregante]

• UI: Add a new Wait for successful checks checkbox by the green Comment button
• Automatically press the "Delete branch" after successful merge, BUT only right then, not "whenever the page loads and the button is there"

[hkdobrev]

FYI, we're now using GitHub Actions and https://github.com/jessfraz/branch-cleanup-action to delete branches automatically after merge. There are a few cases that this action takes care of like skipping protected branches, default branch, base branches of another PR and forks.

[fregante]

That's a good one. The issue with bots is that you have to set them up in each repo

[hkdobrev]

It could be used as a reference to use cases and APIs used.

[fregante]

I just added the pr-branch-auto-delete feature. It's smaller and does not have a checkbox since:

• the branch can be restored
• the feature can be wholly disabled
• those using long lived branches (like develop) might be able to lock down protected branches.

As said by @sindresorhus and @endtoend

This thread now is about "Automatically post comment after merge"

For discussion about pr-branch-auto-delete, comment here: https://github.com/sindresorhus/refined-github/pull/2186 or open a new issue.

Most of the comments here were about that the feature, so I hid them.

[hkdobrev]

@bfred-it Back on the topic of auto-deleting branches, could you please add to the readme? As I had different automation to delete branches in different repos, I was wondering whether it was the RG extension and checked the readme and didn't find it there. Took me a while to be sure it's that.

[fregante]

@hkdobrev:

For discussion about pr-branch-auto-delete, comment here: #2186 or open a new issue.

[ulken]

@fregante I’m a little curious what is actually asked for/what value it brings.

As a user, I check Wait for merge. Then what?

I click Comment which enters waiting state until Merge is pressed and then posts the comment? If yes, what’s the benefit over first merging and then commenting?

If we want to reduce the amount of clicks it sounds like a Merge and Comment button (similar to Close and Comment _Issue_) addresses the issue better?

But maybe I’m totally missing something here. If you could just clear up what you’re after, I’d be happy to give it a go. Thanks!

[ulken]

/cc @sindresorhus Thoughts?

[fregante]

You're not wrong, it's mostly about the expectation that _after the merge_, the merger leaves a thank you note or something like that. But you're right in that it doesn't necessarily have to happen after.

[ulken]

Thanks for replying. I’m sorry if my communication was unclear, but I wasn’t referring to the order of merging/commenting. I get that you want to leave a comment after closing, makes perfect sense.

My concern was around what problem is actually solved by the current solution suggestion? What do you gain? As I see it, all the extra checkbox does is increase the amount of clicks.

If still not clear (and I’m missing out on the obvious), could you help me out with an example scenario? I.e. walk me through the process from a user’s POV.

The way I interpret the current suggestion in the eyes of the user:

1. Enter comment
2. Check Wait for merge
3. Click Comment
   3a. _Waiting..._
4. Click Merge
   4a. _Merge completes_
5. _Post comment_

How is this better than:

1. Click Merge
2. Enter comment
3. Click Comment

Having a Merge and Comment button on the other hand would reduce the above to two steps.

Like I said, I must be missing something here. I just need to understand what in order to attempt this.

And if you feel like it’s not worth the time explaining, that’s fine. Thank you :)

[fregante]

Right, we agree on that, it’s not necessarily better, it’s just seemed like the right order of operations.

As for the amount of clicks: it’s unchanged. Both checkboxes (one for the merge, one for the comment) would be automatically checked and only appear if necessary, so:

1. Click merge (wait for checks already checked
2. Click comment (wait for merge already checked)

If we change the merge button to Merge and comment, such button would submit the content of the comment box BELOW it. No fields should be under a submit button, it’s bad UX. We can’t do that.

In short: I think we can close this issue as the order of operations might not be worth the feature complexity.

[ulken]

@fregante 🙏 Thank you for bearing with me! _Finally_ the penny dropped. Then I’m all aboard. If you don’t strongly disagree (i.e. won’t accept a PR no matter what), I’d like to try it out.

Just for the record:

1. I wasn’t suggesting replacing any button, but add another one (again similar to the _extra_ Close and comment on _Issues_).
2. I wasn’t suggesting adding it to the _Merge_ section, but the _Comment_ section (like Close and comment).

PS. To my defense, I still don't find it obvious what is requested from the initial specification/description as it stands. Maybe I haven’t used RGH enough to read in all the patterns used, but if possible I would very much appreciate a little more details around problem statement and solution suggestions in upcoming issues. Feel free to ignore, just trying to give my POV as a newcomer. Thank you! ❤️

[issuehunt-app[bot]]

@sindresorhus has rewarded $48.57 to @fregante. See it on IssueHunt

• :moneybag: Total deposit: $53.97
• :tada: Repository reward(0%): $0.00
• :wrench: Service fee(10%): $5.40