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.
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+
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:
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.