Repository navigation
RC-353 Test Sarif diff - #6418
BartLucien wants to merge 3 commits into
Conversation
Ruling Diff SummaryDetected changes in 223 rule files: 0 issues removed, 29510 issues added. S100 (
|
834f448 to
c020c39
Compare
e26dca6 to
2cb8fbf
Compare
| } | ||
| }, | ||
| "language" : "en-US", | ||
| "results" : [{ |
There was a problem hiding this comment.
⚠️ Bug: Guava SARIF baselines don't match the JSON baselines they replace
The commit is labelled a format migration ("Migrate Guava to sarif"), but I compared each deleted guava/java-*.json at HEAD~1 with its new .sarif, keyed by (uri, startLine), and the expected issue sets differ. File-level issues stored as 0 in JSON and as a missing region in SARIF are equivalent, so I ignored those.
What actually changed:
- Line shifts: many rules have
guava:src/com/google/common/collect/Collections2.javaissues moved by one line, e.g. S6212 170→171, S909 644→645 and 652→653, S9357 302→303, S3398 679→680. S4738 and others are hit the same way. - New expected issues: S5738 goes from 8 to 28 (new
cache/Striped64.javalines 100, 110, 161, 168, 300…), S1161 from 6 to 8 (collect/Ordering.java539, 615), and S4551 from 4 to 5 (primitives/UnsignedBytes.java313). - Removed expected issue:
java-S103.sarifdrops thethirdparty/publicsuffix/PublicSuffixPatterns.java:45result.
The baselines look like they were regenerated from a different analyzer or source state, not converted from the existing JSON. That silently changes what the ruling accepts, and the ruling will fail or hide real regressions against the pinned its/sources checkout. Regenerate the SARIF by mechanically converting the HEAD~1 JSON. If a behavior change is intended, put it in a separate, explicit ruling update.
Was this helpful? React with 👍 / 👎
❌ ErrorsYour PR has failed checks. Please review the issues below and take necessary action before merging. 🚦 3 Pipeline jobs failed
Useful? React with 👍 / 👎 This comment will be updated automatically if new data arrives.🔗 Commit SHA: 754a4a6 | Docs | View more details | Give us feedback! |
2cb8fbf to
754a4a6
Compare
CI failed: Two distinct failures: the ruling notification job found no actual_* artifacts because the upstream ruling QA job failed (cause unclear from logs), and the Guava ruling test failed in LITS on an out-of-range expected location at Collections2.java line 306 (column 43 on a 15-character line), likely tied to the SARIF migration of the Guava expectations.OverviewTwo unique error templates were found across 6 analyzed logs. One is a notification-job failure caused by missing artifacts, and the other is a Guava ruling test failure from an invalid expected location. The Guava failure is the only one directly linked to this PR's changes. FailuresGuava LITS invalid expected range (confidence: medium)
Ruling notification job found no actual_* artifacts (confidence: medium)
Summary
Code Review
|
| Auto-apply | Compact | Unblock |
|
|
|
Was this helpful? React with 👍 / 👎 | Gitar
|
|
This PR is stale because it has been open 7 days with no activity. If there is no activity in the next 7 days it will be closed automatically |





Part of
Summary by Gitar
eclipse-jettyandguavasonar-lits-pluginto 0.13.0.16172 inJavaRulingTestmasterThis will update automatically on new commits.