Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add work queue tracking in triagebot DB #1879

Merged

Conversation

apiraino
Copy link
Contributor

@apiraino apiraino commented Jan 7, 2025

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/rust will 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 show to 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:
screenshot-20240403-104629

Failed self-assignment:
screenshot-20240403-104717

r? @jackh726

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 apiraino force-pushed the assign-prs-based-on-work-queue-take-3 branch 4 times, most recently from d917ccf to 886116c Compare January 8, 2025 18:08
@apiraino apiraino marked this pull request as ready for review January 8, 2025 18:39
src/handlers/assign.rs Outdated Show resolved Hide resolved
Copy link
Member

@jackh726 jackh726 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just double checking, we don't have to do anything fancy with the db before merging, right

src/handlers/assign.rs Outdated Show resolved Hide resolved
src/handlers/assign.rs Outdated Show resolved Hide resolved
src/handlers/pr_tracking.rs Outdated Show resolved Hide resolved
src/handlers/assign.rs Outdated Show resolved Hide resolved
src/handlers/pr_tracking.rs Outdated Show resolved Hide resolved
@apiraino
Copy link
Contributor Author

Just double checking, we don't have to do anything fancy with the db before merging, right

Correct, the DB schema should be already ready to process the review assignments. The case of review_prefs.max_assigned_prs is null is handled.

This check is specifically used when assigning from the Github web UI

Signed-off-by: apiraino <[email protected]>
@apiraino apiraino force-pushed the assign-prs-based-on-work-queue-take-3 branch from 886116c to 5afc243 Compare January 14, 2025 14:47
@apiraino apiraino requested a review from jackh726 January 14, 2025 15:08
Copy link
Member

@jackh726 jackh726 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We talked a bit in DMs - there are certainly things we could do to minimize the risk (bubble up potential db failures instead of expecting, land the db changes separately, fallbacking to existing non-filtering if db failture), but these aren't needed.

Let's land this.

@jackh726 jackh726 merged commit ba5e479 into rust-lang:master Jan 16, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants