-
Notifications
You must be signed in to change notification settings - Fork 85
Pick reviewer who is not previous assignee when r? group #1958
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
base: master
Are you sure you want to change the base?
Conversation
Thanks for the PR! I think that we should first discuss the design though. I'm not sure if rerolling based on the diff is the most intuitive solution in all cases. If someone did I opened a topic about this on Zulip: https://rust-lang.zulipchat.com/#narrow/channel/224082-triagebot/topic/.40rustbot.20reroll/with/514122139. |
I modified the logic: I'll comment my changes in the code. |
src/handlers/assign.rs
Outdated
// TODO: only NoReviewer can be reached here! | ||
| e @ FindReviewerError::ReviewerIsPrAuthor { .. } | ||
| e @ FindReviewerError::ReviewerAlreadyAssigned { .. } | ||
| e @ FindReviewerError::ReviewerOnVacation { .. }, | ||
| e @ FindReviewerError::ReviewerOnVacation { .. } | ||
| e @ FindReviewerError::ReviewerPreviouslyAssigned { .. }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth noting here. Should we use unreachable!()
except NoReviewer
?
src/handlers/assign.rs
Outdated
let previous_reviewer_names = get_previous_reviewer_names(ctx, issue).await; | ||
let is_previously_assigned = previous_reviewer_names.contains(&candidate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is used to know if the candidate
is a previous reviewer.
src/handlers/assign.rs
Outdated
} else if expansion_happened && is_previously_assigned { | ||
// **Only** when r? group is expanded, we consider the reviewer previously assigned | ||
// `r? @reviewer` will not consider the reviewer previously assigned | ||
Some(FindReviewerError::ReviewerPreviouslyAssigned { | ||
username: candidate.clone(), | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added logic here to determine if it's a previous Reviewer here only when r? group
(expansion happened).
src/handlers/assign.rs
Outdated
|
||
async fn get_previous_reviewer_names(ctx: &Context, issue: &Issue) -> HashSet<String> { | ||
if cfg!(test) { | ||
return HashSet::new(); | ||
} | ||
|
||
// Get the state of the warnings for this PR in the database. | ||
let mut db = ctx.db.get().await; | ||
let state: IssueData<'_, Reviewer> = | ||
match IssueData::load(&mut db, &issue, PREVIOUS_REVIEWER_KEY).await { | ||
Ok(state) => state, | ||
Err(_) => return HashSet::new(), | ||
}; | ||
|
||
state.data.names | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This corresponds to set_assignee
, which stores, and this function is used to read from the database. cfg!(test)
returns null in order to pass the tests
.
let names: Vec<_> = names.iter().map(|n| n.to_string()).collect(); | ||
match ( | ||
candidate_reviewers_from_names(&self.teams, &self.config, &self.issue, &names), | ||
candidate_reviewers_from_names(&ctx, &self.teams, &self.config, &self.issue, &names) | ||
.await, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change the tests into async because candidate_reviewers_from_names
is async.
Can you please update the description with a detailed explanation of what is changing. From the title it is not clear to me what this is doing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I think about it, remembering the previous requested name (r? name
) would be required for rustbot reroll
, but it shouldn't be required at all when we are just modifying the request logic to skip the existing reviewer.
In other words, you can get the current assignee directly from the issue
passed to the handler. Then we should modify the assignment logic to ignore the previous assignee if a team (not a specific user) was requested.
src/handlers/assign.rs
Outdated
@@ -678,7 +711,7 @@ async fn find_reviewer_from_names( | |||
} | |||
} | |||
|
|||
let candidates = candidate_reviewers_from_names(teams, config, issue, names)?; | |||
let candidates = candidate_reviewers_from_names(ctx, teams, config, issue, names).await?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that #1947 completely refactors these tests and provides them access to an actual database, so it might be better to base the code on top of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, when #1947 is merged, I'll rewrite the test.
As discussed in #triagebot > @rustbot reroll @ 💬, I optimized the logic for However. the use of |
|
Hmm, I was thinking that we only ignore the current reviewer, not all previously assigned reviewers 🤔 I'll ask others on Zulip. |
OK, can the description be updated to include that? Or, if the design hasn't been concluded, can this be marked as a draft until it is ready? Also, this doesn't seem like it would close #1762, would it? That seems like a different thing of the ability to say "I want triagebot to pick someone else". |
FWIW, we have been discussing this in https://rust-lang.zulipchat.com/#narrow/channel/224082-triagebot/topic/.40rustbot.20reroll/with/514415765, and me and Jieyou Xu thought that having an explicit reroll command might not be needed if we make this change to the assignment logic. |
Failed to set assignee to
|
1 similar comment
Failed to set assignee to
|
Failed to set assignee to
|
Failed to set assignee to
|
cbbb5af
to
b0574b6
Compare
This commit optimized the logic for `r? group`. Each time an assignee is set, it is stored in the database, and when we use an r? group, such as `r? compiler`, it will take out the previously assigned reviewers from the database to avoid to assign a previous assignee. Signed-off-by: xizheyin <[email protected]>
I rebase this PR to the newest version of master branch that is compatible with the latest |
Hi, just wanted to note that I'll be at https://rustweek.org/, so I might not be able to take a look at this for a few days, but it's at the top of my TODO list :) |
It looks great. Have fun! I don't think the demand for this pr is so urgent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thank you. Could you please also add some tests? You could add a method to AssignCtx
that will store a set of previously assigned names into the DB, and then check that these names will be ignored when expanded from a group/team, and will not be ignored when requested directly.
@@ -92,9 +93,23 @@ const REVIEWER_ALREADY_ASSIGNED: &str = | |||
|
|||
Please choose another assignee."; | |||
|
|||
const REVIEWER_ASSIGNED_BEFORE: &str = "Requested reviewers are assigned before. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const REVIEWER_ASSIGNED_BEFORE: &str = "Requested reviewers are assigned before. | |
const REVIEWER_ASSIGNED_BEFORE: &str = "Requested reviewer(s) were already assigned before. |
/// State stored in the database | ||
#[derive(Debug, Clone, PartialEq, Default, serde::Deserialize, serde::Serialize)] | ||
struct Reviewers { | ||
/// List of the last warnings in the most recent comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong comment.
// Special account that we use to prevent assignment. | ||
const GHOST_ACCOUNT: &str = "ghost"; | ||
|
||
/// Key for the state in the database | ||
const PREVIOUS_REVIEWER_KEY: &str = "previous-reviewer"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const PREVIOUS_REVIEWER_KEY: &str = "previous-reviewer"; | |
const PREVIOUS_REVIEWERS_KEY: &str = "previous-reviewers"; |
@@ -680,6 +710,8 @@ enum FindReviewerError { | |||
ReviewerIsPrAuthor { username: String }, | |||
/// Requested reviewer is already assigned to that PR | |||
ReviewerAlreadyAssigned { username: String }, | |||
/// Requested reviewer is already assigned previously to that PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Requested reviewer is already assigned previously to that PR. | |
/// Requested reviewer was already assigned previously to that PR. |
write!( | ||
f, | ||
"{}", | ||
REVIEWER_ASSIGNED_BEFORE.replace("{username}", username) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
REVIEWER_ASSIGNED_BEFORE
doesn't seem to contain {username}
? It shouldn't need any replacement.
@@ -963,6 +1008,12 @@ async fn candidate_reviewers_from_names<'a>( | |||
Some(FindReviewerError::ReviewerAlreadyAssigned { | |||
username: candidate.clone(), | |||
}) | |||
} else if expansion_happend && is_previously_assigned { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need to check expansion_happened
here. We should decide per-reviewer basis if they were expanded or not. It's enough to check reviewer_candidate.origin
here.
Closes #1762
This PR implements similar functionality to the reroll, and based on the discussion #triagebot > @rustbot reroll on zulip, it is not necessary for us to implement a separate reroll.
I optimized the logic for
r? group
. Each time an assignee is set, it is stored in the database, and when we use anr? group
, such asr? compiler
, I will take out the previously assigned reviewer from the database to avoid to assign a previous assignee.However. the use of
r? @reviewer
to specify a specific assignee does not exclude the previous assignee, as this is explicitly specified.