Vulnerabilities and Code Smells are added together as Code Smells.

[Kumar Gaurav]

Dear all, I am trying to resolve something bit strange and need some clue why its happening. To explain with the help of an example: When I run analysis with local sonar, I get 1 Bugs, 0 Vulnerabilities and 114 Code Smells. But when I run analysis with remote sonar, I get 1 Bugs, 16 Vulnerabilities and 98 Code Smells. It looks like both vulnerabilities and code smells are being added together as Code Smells in local sonar. Both Sonar has same version (Version 6.7.1 - build 35068) and same quality profiles (default java and xml ones). Any idea why it could be happening?

Screenshot of local sonar:

Screenshot of Remote Sonar:

Thanks a lot. Please let me know if you need any information.

Regards,

Kumar

[Kumar Gaurav]

I checked a rule (that is vulnerability on remote sonar and code smell on local sonar) on remote sonar and I see a mismatch between the rule type. Not sure whether its expected. Screenshot on remote sonar:

Screenshot on local sonar for same rule:

However on quality profile, number of rules (for each Bugs, Vulnerabilities and Code Smells) in both local and remote sonar are same. Not sure whats happening here.

Thanks and Regards,

Kumar

[Colin Mueller]

Can you compare the version of the SonarJava plugin both locally and on the remote version? Sometimes rules get reclassified, and that might explain the results you're seeing (especially since the difference is numbers is that exact)

Unfortunately, I don't believe that's a change that will show up in the Quality Profile changelog like a change in severity does (Hey @SonarSource, that would be cool).

Another thing to look at: when the remote SonarQube instance upgraded to 6.7 (assuming it did upgrade from an earlier version), the concept of built-in quality profiles would have been introduced (previously, one had to click a button to restore built in quality profiles whenever a plugin was upgraded to get the updated quality profiles). I wonder if you are in fact not using the built-in quality profile on the remote version of SonarQube, but that old version that did not update itself and is now sitting there (likely with the word "outdated" at the end of it's name). If that's the case, try switching to the built-in one.

Hope this gets you on the right path!

Colin

[Kumar Gaurav]

Version of SonarJava on both local and remote are same. However I was able to fix it for one project by deleting the project on remote and running the analysis again on remote sonar. Now, I don't want to do it for all projects as history will be lost completely but that would be last resort. I suppose that some rules got reclassified after update and it somehow messed up analysis result. Local sonar version did not go through upgrade so it was showing different result. Somehow the project history is causing issue. Still found no solution except deleting project and recreating.

[Colin Mueller]

Kumar, 

I spoke falsely earlier: upon further investigation, the issue type is coupled tightly with the plugin, not editable on a quality profile (although in my opinion it would still be nice for a changelog item somewhere when that changes, as evidenced here it does cause some confusion). This is different behavior than when issue severity changes on a rule (existing issues get updated with the new severity). I'm sure there's a reason it's like this today: the measure changes would be noisy if all issues associated to a rule changed, but it does seem inconsistent.

(I'd also add that if you can change the issue type on an individual issue, it would make sense that you could edit that in a quality profile as well, but that's not the case today.)

What you can do instead of deleting projects when you run across this is utilize the "Bulk Issue Change" tool. After drilling down to the rule in the [Individual Project] > Issues section of your your remote instance, click on the Bulk Change button and then use that to change the issue type on all those individual issues. Next time you scan, all your measures will be updated (unless you update to SonarQube 7.0, where measures like that are live!)

Can I ask why your scanning on a local instance first? I'm curious what your reason for that is (I imagine it's getting around the lack of preview mode in 6.7+?)

Colin

[G. Ann Campbell]

Hi Guys,

As Colin stated, the type assigned to a rule (and thus to the issues it raises) is set by the plugin. We've worked hard over the last couple years to get our settings right for types and severities. Unfortunately, this has meant a little fluctuation in the interim. 

At the heart of Kumar's confusion is that issues, once raised, are not updated by subsequent analysis except to close them. So if issue i1 is raised by a version of rule r1 that's configured as a Code Smell, then i1 is raised as a Code Smell and it stays a Code Smell even after an update to the supplying analyzer changes r1 to a bug.

@Colin, you're right that it would be nice if change logs reflected these rule category changes, so I've entered https://jira.sonarsource.com/browse/SONAR-10443, but there are no timelines for this.

HTH,

Ann

[Colin Mueller]

Thanks Ann. :)

Colin

[Kumar Gaurav]

Thanks a lot Colin and Ann. Information has been very useful. I will use Bulk Issue Change tool next time I see this happen. @Colin: yes you are right :) I am scanning on local instance as there is no preview mode anymore. I am using SonarLint which is awesome (compile time warnings) but still I want to make sure that the code I am pushing is going to pass quality gates in build environment (I have same quality profile and quality gate setup in my local instance).

Thanks again guys for the help..

Kumar

[Colin Mueller]

Alternatively, Kumar, you could remove an analysis that triggered a quality gate failure: https://docs.sonarqube.org/display/SONAR/Managing+Project+History, and upon next analysis (technically you'd have to do the passing analysis first, since you can't delete your most recent analysis) see your history is cleared up.

All of that aside, at the end of the day: is a quality gate failure in your project history really a bad thing? If you fix the failure, that only demonstrates that you were quick to respond to the quality gate failure, and that the feedback loop SonarQube provides is working. 

All in all, it seems like a lot of overhead for something that's not really a bad thing!

Colin