You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We had a discussion about the review queue on Zulip, and a simple actionable point that came out of it is: rustbot should wait for CI to turn green before assigning a reviewer, to avoid the reviewer needing to remember to check back on the PR later.
As a corollary, it would be nice if @rustbot ready also waited for CI to turn green. In both cases rustbot could say "waiting for CI to turn green" (or set a waiting-on-CI label) to inform the author of what's happening.
The text was updated successfully, but these errors were encountered:
a) Apply a waiting-on-ci (or ci-running) on a new PR and when the CI completes, remove that label. Triagebot should react to the event "removed waiting-on-ci label" by throwing a dice and find a reviewer.
or
b) the triagebot should keep an internal state of the PR and choose the reviewer when the CI becomes green
Option (a) a bit easier to implement, but in both cases it should be clarified if there a hook of any kind to be notified that "CI for PR #000 is now green".
It is possible to listen for webhooks related to check suites assigned to a branch/PR, and find out that it all the workflows of the check suite were green, but that is a bit involved (new bors works like this). I'm not sure if there's a simpler way.
We had a discussion about the review queue on Zulip, and a simple actionable point that came out of it is: rustbot should wait for CI to turn green before assigning a reviewer, to avoid the reviewer needing to remember to check back on the PR later.
As a corollary, it would be nice if
@rustbot ready
also waited for CI to turn green. In both cases rustbot could say "waiting for CI to turn green" (or set awaiting-on-CI
label) to inform the author of what's happening.The text was updated successfully, but these errors were encountered: