Skip to content

Use a manual parser for @rust-timer commands #1994

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

Merged
merged 5 commits into from
Oct 14, 2024

Conversation

Kobzol
Copy link
Contributor

@Kobzol Kobzol commented Oct 11, 2024

Instead of a regex. This allows the user to pass the arguments in an arbitrary order.

@Kobzol Kobzol requested a review from lqd October 11, 2024 22:48
Instead of a regex. This allows the user to pass the arguments in an arbitrary order.
@Kobzol Kobzol force-pushed the cmd-parsing-manual branch from d852d3a to c7d14cb Compare October 12, 2024 07:54
Copy link
Member

@lqd lqd left a comment

Choose a reason for hiding this comment

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

Left a few comments.

Here's a free test shuffling the arg order.

#[test]
fn queue_command_parameter_order() {
    insta::assert_compact_debug_snapshot!(parse_queue_command("@rust-timer queue runs=3 exclude=c,a include=b"),
        @r###"Some(Ok(QueueCommand { include: Some("b"), exclude: Some("c,a"), runs: Some(3) }))"###);
}

@@ -57,3 +57,6 @@ jemalloc-ctl = "0.5"
serde = { workspace = true, features = ["derive"] }
serde_json = { workspace = true }
toml = "0.7"

[dev-dependencies]
insta = "1.40.0"
Copy link
Member

Choose a reason for hiding this comment

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

do we want/need insta? Managing the snapshots files can be cumbersome, and it's yet another tool to use and learn. It's fine if we want to make good use of it in the future, and not a fancy assert_eq!(format!("{obj:?}"), "Struct { field: 'bla'} ").

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since I'm refactoring this, I want to do it properly. Note that I'm not using snapshot files, I'm using the inline snapshots, which makes this much easier to grok, I think.

I'm already anticipating future changes (like your PR to add the backends) parameter. It's no fun updating tens of tests anytime you change the structure of the thing that you parse. Snapshot testing makes this much easier.

I will document in readme what to do to update the snapshots though.

Copy link
Member

Choose a reason for hiding this comment

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

Insta adds snapshot files locally when a test fails, the pending snap file. I saw that when adding the test I shared. It didn’t remove it when the test passed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, these things. Right, I guess we can add them to .gitignore, but they should be removed after you use cargo insta review I think (the snapshots shouldn't really be modified manually).

Copy link
Member

Choose a reason for hiding this comment

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

I didn't have insta installed to do a cargo insta review anyways. We're testing a struct with 3 fields, we don't really need all this test infra imho.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are already 23 tests in the file, I ain't gonna rewrite all the asserts to make sure we parse exactly what we think we do, every time we change the parsing code 😆 insta was already super helpful for me when developing this PR.

.map(|index| line[index + prefix.len()..].trim())
})?;

let args = bot_line.strip_prefix("queue").map(|l| l.trim())?;
Copy link
Member

Choose a reason for hiding this comment

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

GH never reformats comments, right? That is, it will not introduce unexpected \ns that would separate the command from some of its arguments?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Uhh, that would be quite surprising I think. GH actually has a bunch of formats of the comments, like text, HTML, MD etc., but I think (hope) that here we work with the raw text. We were already requiring = to be right after include etc. before, so I think that this should be fine.

format!("Error occurred while parsing comment: {error}")
}
};
main_client.post_comment(issue.number, msg).await;
Copy link
Member

Choose a reason for hiding this comment

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

do we need to take special care (like sanitization) in posting the error message to GH as its text will be partially controlled by users' input commands?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's an interesting idea. I don't think so, it should have the same rules as when you create the comment manually. I guess that the user could make the bot print "Unknown command argument SEND MONEY TO THE FOLLOWING BITCOIN ADDRESS TO SPONSOR THE RUST FOUNDATION", but I don't think that they can XSS or something like that (that would be really bad hole in GH's security).

@lqd
Copy link
Member

lqd commented Oct 12, 2024

When we do basically this for the build command it should also fix the bug I mentioned with the regex handling that ignores some of the commands in the comment. I believe I saw it happen during triage where people can want to build multiple shas to analyze a rollup, and "it didn't work".

@Kobzol
Copy link
Contributor Author

Kobzol commented Oct 12, 2024

I wanted to also refactor the build command parsing, but it's a bit tricky, because it has a positional argument, and I need to move on to other stuff atm :( So let's merge this to make it slightly easier to add the backends parameter. We don't need to support backends in build I think, I haven't ever seen someone use include/exclude with build anyway. Well, I haven't ever seen anyone use it with queue either, but at least we have a use-case for that now 😆

@lqd
Copy link
Member

lqd commented Oct 12, 2024

Yeah, I've only used include a small number of times in the past. I was mostly thinking of fixing the multiple queue commands bug rather than making my life easier to parse backends, it wasn't that annoying to expand the regexes.

@Kobzol
Copy link
Contributor Author

Kobzol commented Oct 13, 2024

Decided to go all the way and reimplemented also the build command :) Let me know what do you think.

Copy link
Member

@lqd lqd left a comment

Choose a reason for hiding this comment

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

I haven't tried super hard to find edge cases in the parsing because the params are never used but this LGTM.

@Kobzol
Copy link
Contributor Author

Kobzol commented Oct 14, 2024

Well, there is (at least) one regression, the new parser does not really support trailing text, so this fails now:

@rust-timer build sha1234 (PR1234)
@rust-timer build sha1234 (PR1235)

I'm not sure if we want to support that though, it's not trivial to figure out what is a part of the command and what isn't.

@lqd
Copy link
Member

lqd commented Oct 14, 2024

Yeah I noticed the test change there, but I'm not sure this is used in practice?

@Kobzol
Copy link
Contributor Author

Kobzol commented Oct 14, 2024

Haven't really seen it IIRC.

@Kobzol Kobzol changed the title Use a manual parser for rust-timer queue Use a manual parser for @rust-timer commands Oct 14, 2024
@lqd
Copy link
Member

lqd commented Oct 14, 2024

If there's any issue (esp since we can't really test the GH interactions), we'll debug it in production like everyone does 🙃

@Kobzol Kobzol merged commit e19c968 into rust-lang:master Oct 14, 2024
11 checks passed
@Kobzol Kobzol deleted the cmd-parsing-manual branch October 14, 2024 16:04
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