E.g. I have an approved PR. It has 3-times flapped CI tests.
At now, I cannot do anything and must wait until someone with access to bors commands retry CI run.
I think, it can be useful if some reviewer can mark a commit in PR as "OK to run bors by author", then I as an author would be able to run retries, perf and other similar commands for bors.
There's already @bors delegate+
delegate=NAME: Allow NAME to issue all homu commands for this PR.delegate+: Delegate to the PR owner.Quoted from https://bors.rust-lang.org/
Doesn't it give too many opportunities to PR author? E.g. can I change may PR and try to merge it without review?
I think, more narrow permissions would be more easily given by reviewers.
And, maybe some actions like retry should be allowed automatically if PR was approved.
That's true. It's commonly used though with - I suppose somewhat trusted - people who contributed before, e.g. when a reviewer says "you still need to make this small change, then you may mark this PR as accepted by me". E.g I've gotten a delegate on my PRs myself 3 times before, each time it was about "mark this as accepted after this particular small change".
I don't think that it's all that common that such a high number of retrys are required; still it might make sense to give more narrow permissions; one use-case I have in mind is that you could specifically delegate permission for one particular command (often e.g. an r+ command with specific reviewer and perhaps some control of the rollup flags), which would even help the contributor so that he/she/they would not need to come up with that command themself.
Yes, I think, explicitly adding allowed commands can be useful.
However, it would be more tedious for PR reviewers (e.g. list 5 commands is not easy) and it seems they are already too busy (I see a lot of unmerged PRs open in rust repo).
Also, assuming that most PRs open by people who can call bors already, reviewers can often forget to enable commands.
Maybe we should make combined solution: e.g. allow some commands automatically and allow some commands by explicit request from reviewers.
I think, delegation makes most sense when you're anticipating the need for a specific command ahead of time; and in this case it's not that much more tedious. If you retry due to a "known flaky test", you might as well also do something like (my own stand-in syntax) @bors delegate+ (retry), which would be potentially lower-risk (I'm not 100% sure whether retry only works on already accepted PRs), and it would also be able to make bors automatically inform the user not only with a message like "
@ username can now approve this pull request", but could be more specific with " @ username can now use the command @bors retry for this PR".
As I mentioned above, when the necessary command is more complex, e.g. @bors r=reviewernameXYZ rollup=always, then this would be probably super useful, and nobody would need to explain to more inexperienced contributors what exactly they should do. And more inexperienced contributors could be less insecure about executing the wrong bors command because they wouldn't even be able to use the wrong comand anymore. (I certainly was a bit insecure and needed to lookup bors commands in-depth before being able to react appropriately to the first delegate I received!)
As mentioned above, I'm not entirely certain I know whether retry is fully safe to use (i.e. it accepts only commits that are already accepted). Reading something like rust-lang/homu#159, it seems like homu (bors) might not be designed with more safe or less safe commands in mind (yet).
In any case, it seems like a decent idea to open an issue on Issues · rust-lang/homu · GitHub about the ideas we're discussing here.
Having @bors try permission is effectively equivalent to @bors r+ permission AFAIK by using a modified workflow to access a github token with write permission to the rust-lang-ci/rust repo, which probably can be abused to push a commit of your choosing to rust-lang/rust. It also has access to the aws s3 token to upload new rustc releases. (maybe even modify existing ones?)
I believe it doesn't allow retry after pushing to a PR branch. I also don't think it works before a pr is either approved (@bors r+) or tried (@bors try). Don't quote me on that though.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.