Support sarif as a report type - #3045

[arturbosch]

New optional report format which can be plugged via --plugins detekt-report-sarif.jar:

Output preview via the VSCode extension:

CI will fail due to not a published version of sarif4j. We need to wait until #3045 gets an answer from the sarif authors.

[schalkms]

I just skimmed through the code change list. Hence, I only have some general questions.
Is there a roadmap for the Java support? I'm not sure whether reinventing the wheel by implementing the SARIF support in Kotlin is the right approach here?

[arturbosch]

I just skimmed through the code change list. Hence, I only have some general questions.
Is there a roadmap for the Java support? I'm not sure whether reinventing the wheel by implementing the SARIF support in Kotlin is the right approach here?

When the official MS java support will be out, we can and should migrate to it.
We do not reinvent any wheels here, just generating POJOs :).
Please also see my comment in #3045 (comment).

[schalkms]

Good to know. Thanks for the explanation. I really appreciate your work for supporting this feature. For me this PR looks fine.

[cortinico]

is this randomly generated?

[arturbosch]

Yes, I generated it randomly once with UUID.getXXX().
As I've understand it, the guid needs to be the same between all detekt 1.x.y runs.
Correct me if I'm wrong here @michaelcfanning

[michaelcfanning]

@arturbosch, just checking in on this, as there's strong interest internally at Microsoft for consuming this new report format. Any idea when it might be merged/available?

[arturbosch]

@arturbosch, just checking in on this, as there's strong interest internally at Microsoft for consuming this new report format. Any idea when it might be merged/available?

Hey @michaelcfanning , thanks for interest and the ping.
I've worked on this further locally. I have one last question regarding default -1 values in the scheme which should not appear in the report. I will keep you updated in #3045 later this week.
There are so many good rule improvements in the main branch so I really should get up to speed to finish this and release 1.15.0 xD.

[michaelcfanning]

@arturbosch, glad to help w/any SARIF advice. The large # of optional properties/defaults is definitely a concern depending on your JSON mechanism. The C# SARIF SDK uses a library (Newtonsoft JSON.NET) that automatically elides/hydrates these on save/open. We autogenerated the C# OM that has appropriate attributes for this by writing a custom tool, 'JsonSchema.ToDotNet' that parses the SARIF JSON schema. We could consider a similar trick in your scenario, if your JSON serializer supports similar features.

I took Larry's suggestion and have opened an issue to write a validator that flags all unnecessarily rendered default values. There's a lot of surface here to examine...

Something to keep in mind, though: SARIF which contains this data is valid. You might consider hard-coding eliminating obvious things for now, while considering a more systematic/comprehensive solution.

[codecov]

Codecov Report

Merging #3132 (d6bc64c) into master (d309424) will decrease coverage by 0.01%.
The diff coverage is 78.26%.

@@             Coverage Diff              @@
##             master    #3132      +/-   ##
============================================
- Coverage     80.09%   80.07%   -0.02%     
- Complexity     2648     2651       +3     
============================================
  Files           440      443       +3     
  Lines          8013     8082      +69     
  Branches       1528     1536       +8     
============================================
+ Hits           6418     6472      +54     
- Misses          775      789      +14     
- Partials        820      821       +1     

Impacted Files	Coverage Δ	Complexity Δ
...n/io/github/detekt/report/sarif/RuleDescriptors.kt	21.05% <21.05%> (ø)	0.00 <0.00> (?)
...n/kotlin/io/github/detekt/report/sarif/SarifDsl.kt	100.00% <100.00%> (ø)	0.00 <0.00> (?)
...io/github/detekt/report/sarif/SarifOutputReport.kt	100.00% <100.00%> (ø)	3.00 <3.00> (?)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d309424...d6bc64c. Read the comment docs.

[arturbosch]

@arturbosch, glad to help w/any SARIF advice. The large # of optional properties/defaults is definitely a concern depending on your JSON mechanism. The C# SARIF SDK uses a library (Newtonsoft JSON.NET) that automatically elides/hydrates these on save/open. We autogenerated the C# OM that has appropriate attributes for this by writing a custom tool, 'JsonSchema.ToDotNet' that parses the SARIF JSON schema. We could consider a similar trick in your scenario, if your JSON serializer supports similar features.

I took Larry's suggestion and have opened an issue to write a validator that flags all unnecessarily rendered default values. There's a lot of surface here to examine...

Something to keep in mind, though: SARIF which contains this data is valid. You might consider hard-coding eliminating obvious things for now, while considering a more systematic/comprehensive solution.

@michaelcfanning thanks for the advice.
I've switched to Jackson which allowed to preserve the order of properties and eliminate default values from the report.