-
Notifications
You must be signed in to change notification settings - Fork 76
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
feat: validate proposed change(s) in triagebot.toml for PRs ✨ #1730
Conversation
r? |
r? dev-tools |
src/config.rs
Outdated
pub fn config_file_name() -> &'static str { | ||
CONFIG_FILE_NAME | ||
} | ||
|
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.
why this utility function? Can CONFIG_FILE_NAME
be made public and used directly in handler.rs
?
src/handlers.rs
Outdated
@@ -124,6 +124,29 @@ pub async fn handle(ctx: &Context, event: &Event) -> Vec<HandlerError> { | |||
errors | |||
} | |||
|
|||
async fn validate_triagebot(ctx: &Context, event: &IssuesEvent, errors: &mut Vec<HandlerError>) { |
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.
As far as I can see this function would inject an HTTP call in the issue_handlers
macro which is called quite often. I am a bit worried about the additional overhead on every issue the triagebot is called to handle.
What is your goal here @meysam81 ? validate the triagebot config for a certain repository, right? Can this check happen just once on triagebot startup?
Also the name of this function could be a bit more explicit about its purpose (e.g. validate_triagebot_config
or something similar).
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 function should be placed in its own module at minimum (similar to all the other handlers). I'd emulate something like rustc_commits in terms of structure.
I would expect that if the goal is to validate PRs, then we would do this only on push events. It probably also makes sense to delegate the actual validation to the config module, not just calling toml::from_slice
here.
As you suggested, I refactored the changes into its own module. You may also see a successful run here: meysam81/triagebot-test#2 (comment) |
src/handlers/validate_config.rs
Outdated
let diff = match event.issue.diff(&ctx.github).await { | ||
Ok(Some(diff)) => diff, | ||
wildcard => { | ||
log::error!("Failed to fetch diff: {:?}", wildcard); | ||
return Ok(None); | ||
} | ||
}; | ||
|
||
if diff.contains(crate::config::CONFIG_FILE_NAME) { |
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 have a few concerns about this. IIUC, this fetches the full diff on every PR on every push. That seems like it would be expensive, and potentially slow.
Would it be possible to use the files()
method instead? I would imagine that is more efficient, and is also structured.
Similarly, this looks like it does a string contains
check, which means that if any text anywhere in the patch contains the bytes triagebot.toml
, it would trigger. If it looked at the structured file list, then it should be able to look to see if that file is specifically being modified.
I'm still not sure if hitting the files
endpoint on every push is OK, but I suspect the traffic should be low enough to be fine.
BTW, there is now a merge conflict. |
I'm a bit confused about the approach taken here. It seems to validate the config on every PR opened or pushed. I would expect it to operate like it did before, where it would only validate the config on a PR that is modifying |
src/handlers/validate_config.rs
Outdated
return triagebot_toml.clone(); | ||
} | ||
|
||
log::warn!( |
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 think doing a warn! on every cache miss would pollute the logs with unactionable information. I would expect something like this to be trace or debug. Similarly with the info! above about a hit, that information is likely to add noise.
The main driver for the new approach was to address the expensive HTTP round-trips mentioned here: #1730 (comment) Additionally, at the expense of using a fixed size memory for holding the config (128 total |
src/github.rs
Outdated
pub struct PullRequestFile { | ||
pub sha: String, | ||
pub filename: String, | ||
pub blob_url: String, | ||
pub raw_url: String, |
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.
Are raw_url
and Clone
still needed?
My concern in that comment was about using the In the future, we could potentially cache the |
Hm, so I'm taking a closer look at this, and I need the diff for something else. We're already fetching the diff 3 times in other handlers. I'll try to follow up soon with something that caches that. |
Ok, I posted #1749 to implement caching of the diff (since I need it for something else). If/when that PR is merged, I think this PR can be updated to just call the Sorry about the back and forth on this. |
This adds deny_unknown_fields to Config so that any typo mistakes will be caught by the config validation.
I hope you don't mind, I went ahead and applied some of the changes suggested above. I also made a few other changes:
Thanks for helping with this! |
fixes rust-lang/rust#106104
A successful run is visible here: meysam81/triagebot-test#2 (comment)
Some highlights I need to mention here:
hacktoberfest-accepted
to this PR, since the repo is not marked withhacktoberfest
.cargo fmt
, norcargo clippy
not formatting my code? 🤔