Sonar is showing new bugs in old code

SonarQube Server / Community Build
,
1

We are using SonarQube 6.7.3 and sonar java plugin 5.3

We have changed sonar configuration to make byte code available to Sonar and enabled some new rules to quality profile
Changed “clean sonar:sonar” to “clean package sonar:sonar”

Since then it is showing issues in old code as new errors.

We have enabled sonar with svn plugin and provided credentials as well, so we expect it to show new errors on new code only.

Please let me know why it is showing new errors in old code…

2

Hi,

You don’t give any examples, so it’s down to educated guessing on my side, but it’s entirely possible for legitimately new issues to be raised in old code. For instance, let’s say you update methodA so that it might now return null. Old calls to methodA must now null-check return values before dereferencing. If they don’t, new null pointer issues will legitimately be raised on those old calls.

HTH,
Ann

3

Thanks for the quick reply @ganncamp

I have not made any code changes, still it is showing as sonar violations in my code

From below thread I understand it is because of the mentioned configuration change in my question
https://groups.google.com/forum/#!topic/sonarqube/oEw61qJYR6M

But I could not understand why sonar is showing new errors in old code. Because it can get the code committed date from svn.

Also help me find a way to handle this new issues

4

Hi,

Issues are only backdated in certain circumstances:

  • on first analysis of a project
  • on issues raised by rules newly added to a profile
  • on the first analysis after a plugin upgrade

At all other times, all newly found issues are going to be “new”. This ticket explains why we don’t just blindly backdate all the time.

Ann

1 Like
5

Thank you @ganncamp .

For my case I got new issues in old code because of providing byte code to sonar.

I don’t want these issues labelled as “new”.

Could you please help me find a way to handle this case

6

I think Sonar should back date the new issues came up because of providing byte code at later point of time.

Please advice.

7

Hi Rama,

Not providing bytecode was actually a misconfiguration, so from there on it’s expected that fixing it might raise new issues. @ganncamp described the legit use-cases where SonarQube performs issue backdating, and there is no plan to have SonarQube backdate issues in the cases of past misconfigurations that have been addressed.

Not to mention that this should remain a rare situation, so ultimately it’s under your control to (punctually) perform these changes in between two versions of your products, so that you can then pursue clean code on a clean Leak Period.

8

Thank you @NicoB,

I understood that fixing misconfiguration raises new issues. But labeling them under “new” seems a bit odd to me.

“perform these changes in between two versions of your products” sounds fine to me, I will do that.

Thanks again for your time…

1 Like