CODEWITHSUNDEEP
javasonarqubecobertura
Sinc
Sinc

Reputation: 671

Cobertura changes Sonar violations

My co-worker found this morning that compiling a project with Cobertura enabled changes the sonar results on the same project.

On this particular project we ran a build with sonar:sonar and then ran it again with cobertura:cobertura sonar:sonar.

The sonar results in the comparison are now showing that without Cobertura we have 7/78/153/24/0 violations of the 5 severities, but with Cobertura it changes to 7/81/94/24/0, and in particular finds 3 new critical violations and 15 new major violations that aren't found without Cobertura.

One of the biggest changes is that without Cobertura there are 60 violations of the rule against empty methods (many of them constructors) and with Cobertura only 3 of those are reported.

If Cobertura only prevented violations from being found we could run the two independently, but since some violations are only found with Cobertura enabled it seems like we would have to do two separate Sonar analyses.

Is this a known interaction? Is there any workaround other than doing Cobertura and Sonar in separate builds? And using both sets of results to get the best data?

Upvotes: 1

Views: 167

Answers (2)

Sinc
Sinc

Reputation: 671

User error. :-(

It turns out that the user had run a mvn clean prior to running the sonar:sonar with cobertura, so as implied by benzonico, the findbugs rules that have to analyze compiled code didn't run. Only the rules that are run on source code, like the java plugin, generated results. That's why we were missing a bunch of rules and results.

We still have inconsistencies between Bamboo and manual builds, but that would be a topic for a separate post.

Upvotes: 1

benzonico
benzonico

Reputation: 10833

Based on the comment you made let me explain what it seems to be happening: You are using FindBugs via SonarQube (rules you are mentioning are findbugs rules)

First let's think about the two tools involved here and how they work (roughly) :

  • FindBugs : it is a static analysis tool based on bytecode : it will read bytecode and raise issue when it detects bad pattern.

  • Cobertura : Coverage tool : how does this work ? it instruments the bytecode to place probes and when tests are run keep track of which probes where hit or not.

Then you can understand where the issue might be : FindBugs ends up analyzing the bytecode instrumented by Cobertura. That would explain why you have some new issues and why some of the empty methods issues are removed when analyzing with cobertura.

To avoid this issue you have to be sure your bytecode files are not instrumented when you analyze them with FindBugs but (disclaimer, I develop the sonar java plugin so I might be a little biased here ;) ) I would recommend you to stop using FindBugs in favor of the SonarQube Java Analyzer which won't have this issue as its analyzer approach things slightly differently (see this blog post about that)

Upvotes: 1

Related Questions