We use Sonar (SonarQube, Enterprise Edition, Version 7.3) for the analysis of our java-projects and we use the new branching-feature.
Some days ago we did an analysis for one of our java-projects for Git-tag v_2017_08_22_MJ in a short lived branch (SLB).
The last analysis on the main-branch (and the sonar.branch.target for the SLB-analysis is set to the main-branch) was done about 2 years ago for version v_2015_09_19_PR. Since analysis of the main-branch and now we introduced 47 new rules into the quality-profile.
The result of the SLB-analysis is 11 issues, but all these 11 issues occur in old code, code that didn’t change between version v_2015_09_19_PR and v_2017_08_22_MJ. All these 11 issues affect the 47 new rules that didn’t yet exist 2 years ago. That’s why these issues were not found in the old analysis of the main-branch.
So on the one hand the issues are discovered for the first time (because of introducing new rules), so they are “new”, but on the other hand they are discovered in old code.
For the purpose of preventing new issues in old code Sonar introduced the means of issues-backdating (see for example https://blog.sonarsource.com/sonarqube-6-3-in-screenshots , “Backdating issues raised by new rules on old code…”).
In my example the backdating works in the SLB, the 11 issues are backdated (“5 years ago” and “3 years ago”), but nevertheless they are treated as “new” so that the QualityGate is failed/Status=ERROR.
Does Sonar work here as designed or is it perhaps a bug? If it works as designed, couldn’t the behavior be changed? I’d like not to get issues for code that I didn’t change, no matter if I do the analysis per SLB or LLB.