Add work queue tracking in triagebot DB #1879
Conversation
Signed-off-by: apiraino <[email protected]>
Add checks in multiple points when identifying or finding an assignee. Filter out team members currently not having capacity, return messages instructing what to do in case the assignment is rejected. Signed-off-by: apiraino <[email protected]>
apiraino
force-pushed
the
assign-prs-based-on-work-queue-take-3
branch
3 times, most recently
from
0ac2d52 to
d917ccf
Compare
This check is specifically used when assigning from the Github web UI Signed-off-by: apiraino <[email protected]>
apiraino
force-pushed
the
assign-prs-based-on-work-queue-take-3
branch
from
d917ccf to
886116c
Compare
| FROM review_prefs r | ||
| JOIN users on users.user_id=r.user_id | ||
| AND username = ANY('{{ {} }}') | ||
| AND CARDINALITY(r.assigned_prs) < LEAST(COALESCE(max_assigned_prs,1000000))", |
There was a problem hiding this comment.
A note about this SQL dance, it is a safeguard against null fields to be able to do a number comparison. CARDINALITY returns the number or array items even when empty, LEAST(COALESCE(...)) returns a number when max_assigned_prs is null.
There was a problem hiding this comment.
Does this need to be r.max_assigned_prs? (If not, should it for clarity?)
| FROM review_prefs r | ||
| JOIN users on users.user_id=r.user_id | ||
| AND username = ANY('{{ {} }}') | ||
| AND CARDINALITY(r.assigned_prs) < LEAST(COALESCE(max_assigned_prs,1000000))", |
There was a problem hiding this comment.
Does this need to be r.max_assigned_prs? (If not, should it for clarity?)
| usernames | ||
| ); | ||
| let result = db.query(&q, &[]).await.context("Select DB error")?; | ||
| let mut candidates: HashSet<String> = HashSet::new(); |
There was a problem hiding this comment.
Nit: you could initialize with the known capacity?
| @@ -66,18 +70,60 @@ pub(super) async fn handle_input<'a>( | |||
| if matches!(event.action, IssuesAction::Unassigned { .. }) { | |||
| delete_pr_from_workqueue(&db_client, assignee.id, event.issue.number) | |||
| .await | |||
| .context("Failed to remove PR from workqueue")?; | |||
| .context("Failed to remove PR from workq ueue")?; | |||
| and there are no other candidates.\n\ | ||
| Use `r?` to specify someone else to assign.", | ||
| User(s) `{}` are either the PR author, already assigned, or on vacation. \ | ||
| If it's a team, we could not find any candidates.\n\ |
There was a problem hiding this comment.
Not needed, but we could just be smart and use a message tailored to if it was a team or not.
| FROM review_prefs r | ||
| JOIN users ON users.user_id = r.user_id | ||
| WHERE username = $1 | ||
| AND CARDINALITY(r.assigned_prs) < LEAST(COALESCE(max_assigned_prs,1000000));"; |
There was a problem hiding this comment.
So, I can somewhat see an argument for having the check be done the same as when fetching users, but it's a bit weird that we don't just fetch the number of assigned prs and max assigned prs and check it outside the db.
For consistency, I think let's keep it this way, but put a comment.
Rebase of #1786
This implements the new way of assigning pull requests reviews (designed in #1753). When this PR is merged, PRs in
rust-lang/rustwill be assigned based on user preferences. These can be queried from Zulip (see docs).If no preferences are set, PRs will be just assigned (like always).
There are multiple points where PRs are assigned (via comment or using the GH UI), I've tried to cover all cases, took some time to test them all. The amount of changes reflect that it is not so easy to catch all spots where this happens. I wish I could make a smaller patch but I think this is an all-or-nothing situation where all cases should be handled at once.
Also modified the zulip triagebot command
work showto return the # work queue capacity set by the user. This is helpful in case a PR assignment is rejected. A PR to update the documentation will follow-up after merge of this.If a PR assignment is rejected we will return a message with some context. Examples:
Failed PR assignment to a user:
Failed self-assignment:
r? @jackh726