Use GitHub Approved Review to indicate r+?

#1

I’m new to Bors and still working to understand the model. I have a question which I haven’t been able to find answered anywhere.

Would consideration be given to adding a feature to Bors such that an Approved GitHub review can be the equivalent of a bors r+ command?

It seems to me that having this would be a workflow improvement as users could continue to use GitHub reviews in the way they are used to.

It looks like bonnyci and https://mergify.io both use GitHub reviews to provide the approval signal.

Any comments are appreciated!

1 Like
#2

I’ve considered it, but for consistency’s sake I’d rather not. I know that there are people who maintain multiple projects that use bors, and if it was present as a configurable option, then that would mean that different projects would all behave differently. Clicking the GitHub Approved button and expecting it to trigger a merge, only to realize an hour later that bors was configured not to do so, stinks.

More than that, I also know that there are existing users of bors who rely on GitHub Reviews not triggering a merge, so while I don’t want it to be configurable, I also don’t want to unilaterally change bors to behave this way.

It might be a bit of a lost cause since mergify is becoming popular (BonnyCI, on the other hand, seems to be abandonware). But mergify is super-configurable, and I’ve seen other tools that exclusively use comments, or even labels, to trigger a build. I can’t make all of the build automation tools behave consistently, but I’d at least rather make bors projects consistent with each other.

If you’re looking for a way to use bors with less typing, I’ve been messing with a browser extension to add a “bors r+” button to the pull request review interface. It’s still pretty experimental, but it works when I try it.

1 Like
#3

For what it’s worth, I just loaded it up in the Edge preview using Chromium, and it worked out of the box. Thank you!

1 Like
#4

if it was present as a configurable option, then that would mean that different projects would all behave differently.

What if it wasn’t a configuration option?

What if you could always either comment bors r+ or approve the PR on GitHub?

This way you can make use of existing toolchains around GitHub approvals, like how GitHub’s branch protections in tandem with CODEOWNERS files will automatically add required reviewers.

Of course you could still require both GitHub reviews and a bors r+ comment, but then you run into the exact problem you were describing: You might review a PR and approve it and then come back hours later to find out you were supposed to also comment bors r+

#5

But then this would break all the projects that currently use Bors that expect a GitHub approval to NOT trigger Bors.

2 Likes
#6

I think we should support this. A lot of people use github standard workflow which is the github approval. I have been actually writing an RFC for this and realized I need to search if there were any discussions for it.

I think we can allay the main concern here by allows bors to print a welcome message on all PRs saying either one of the following:

  • Thanks for your contribution. Waiting for 1 Github approval.
  • Thanks for your contribution. Waiting for either 1 Github approval or 1 Bors approval.
  • Thanks for your contribution. Waiting for 1 Bors approval.

We can even add a sub status check for bors on PRs to show one of the following:

  • 1_github_approval
  • 1_approval
  • 1_bors_approval

That way, we make sure the people who use this in multiple projects don't forget the configuration. And this can all be configurable with the bors_approval strategy being default.

NOTE: 1 above is a placeholder. We can set required_approvals to set it.

That should address all the concerns here.