Feature: Add SARIF output support#9078
Conversation
crates/ruff_cli/src/lib.rs
Outdated
| printer.write_statistics(&diagnostics, &mut summary_writer)?; | ||
| } else { | ||
| printer.write_once(&diagnostics, &mut summary_writer)?; | ||
| printer.write_once(&diagnostics, &mut summary_writer, &pyproject_config)?; |
There was a problem hiding this comment.
So one potential issue here is that pyproject_config isn't guaranteed to contain the correct set of enabled rules for all files. Ruff supports hierarchical configuration, so you can have different configuration files that apply to different subdirectories in your project. The pyproject_config here really just represents the settings in the current working directory.
Could we infer the set of rules from the diagnostic messages? (What is this used for on the SARIF side?)
There was a problem hiding this comment.
Gotcha--thanks for that context. SARIF lists the rules applied as part of the tool description so that you can be sure you're getting an apples to apples comparison, rather than just saying both times you checked with a particular rust version.
While the field is not mandatory in the SARIF specification Section 3.19.23 rules property it is required by Github. Also see: Understand Rules and Results
I'm not exactly sure how github would handle having the rules be supplied as only the ones for which diagnostics could be found as that's not documented.
There was a problem hiding this comment.
Alternatively, could we just include all rules?
There was a problem hiding this comment.
Including all rules is probably the safest bet. In my experience with code scanning on github, I've never looked at what checks were done, only the findings, so this is probably closest to the SARIF expectation. My gut is that most people have most rules applied, and only turn off a handful, but I could be wrong, especially for older/larger projects.
Only downsides are if someone complains and then we change it, if others are using it in their CI, the rules set will change, which again, not sure how bad that is and that the file size will be a bit larger.
There was a problem hiding this comment.
Let's try all-rules for now. You can iterate over them with Rule::iter().
| rule: message.kind.rule(), | ||
| level: "error".to_string(), | ||
| message: message.kind.name.to_owned(), | ||
| uri: Url::from_file_path(message.filename()).unwrap().to_string(), |
There was a problem hiding this comment.
If filename is relative here, would this convert it to absolute? I do think filename will always be absolute here... we pass around absolute paths, and expect callers to call relativize_path when displaying user-facing relative paths... But we may want to be defensive (call .canonicalize() or normalize_path or similar).
There was a problem hiding this comment.
This is what I was referring to in the PR body. It'll error if the path is relative, which is why I changed the path in the snapshot files. I'll update to safely handle relative paths, should be straight forward.
There was a problem hiding this comment.
👍 I did see that, but wasn't sure how Url::from_file_path would behave if the path wasn't absolute.
There was a problem hiding this comment.
yeah, normalize_path seems like the right call here, as .canonicalize() will fail if the file doesn't actually exist (a la in test).
|
charliermarsh
left a comment
There was a problem hiding this comment.
I think this is probably good to merge once we change to enumerate all-rules. @C-Hipple do you plan to make that change, or would you like a hand?
|
I was planning on making this change tonight/tomorrow, but if that falls
through I'll let you know as I'll be leaving on a trip. Seems simple
enough and also fix the issue to build for wasm seems straightforward.
…On Tue, Dec 12, 2023, 5:38 PM Charlie Marsh ***@***.***> wrote:
***@***.**** commented on this pull request.
I think this is probably good to merge once we change to enumerate
all-rules. @C-Hipple <https://github.com/C-Hipple> do you plan to make
that change, or would you like a hand?
—
Reply to this email directly, view it on GitHub
<#9078 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBKSYUSPPC5AYNRJ5PRJ33YJDMIFAVCNFSM6AAAAABAOGQWJWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONZYGU2TENJUHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Nice, thanks @C-Hipple! |
|
please don't merge it yet--I'm adding a few more sarif fields |
|
@C-Hipple -- Okay, sounds good. I just removed some of the copy and clone changes since the code seems to compile without them now. I'll wait for you to mark as ready for review. |
|
Thanks--your changes look good. Appreciate your input there as I"m relatively new to rust and was kinda using this issue as a way of getting a bit more familiar. |
|
Any questions let me know. Sorry if I stepped on your toes, didn't realize you were planning more changes! |
Yeah, those were needed at one point with how SarifResults were copying rules into them, was also planning on backing them out but you beat me to it.
no worries! |
|
@charliermarsh I'm happy with the PR now, but I'm really unsure of the last commit--the |
|
@C-Hipple -- What you have there is reasonable! But I'll play around with it and see if it can be improved. |
16d4bf0 to
3f5438b
Compare
|
@C-Hipple -- The only change I made was to use absolute references for the imports that were unused in the Wasm path. It's not a material difference, but it is nice to avoid the unused import ignore. |
|
Unfortunately, |
Summary
Adds support for sarif v2.1.0 output to cli, usable via the output-format paramter.
ruff . --output-format=sarifIncludes a few changes I wasn't sure of, namely:
Test Plan
I built and ran this against several large open source projects and verified that the output sarif was valid, using Microsoft's SARIF validator tool
I've also attached an output of the sarif generated by this version of ruff on the main branch of django at commit: b287af5dc9
django_main_b287af5dc9_sarif.json
Note: this needs to be regenerated with the latest changes and confirmed.
Open Points
[ ] Convert to just using all Rules all the time
[ ] Fix the issue with getting the file URI when compiling for web assembly