Hi! can anyone help me to understand how is possible that a custom rules developed and deployed at 14/01/2020 detects issues “in the past” (i.e. at 14/12/1019)?
Casually the SQ server was upgraded from SonarQube 5.6.7 to SonarQube 7.9.1 at 14/12/2019, but the custom java rules were developed and published for the first time at 14/01/2020.
The plugin containing these rules already exists before upgrade, but a lower version without these rules.
After upgrade the server all applications were reanalyzed. Next month, the custom rules were deployed and after reanalyze the applications, all detected issues for these rules has date of the range between the day of the upgrade and four days more.
Now, the new issues for these rules has more recent dates, but i’m not sure if there are correct. Aparently it has no sense… what kind of change or wrong config may influence in that?
SonarQube typically knows when a line was last changed based on SCM data (when did the last commit on this line occur?). As a result, it can backdate issues to when the line was last touched. That’s probably what happened here.
This prevents those issues from polluting the New Code Period – since those issues were always there, they just weren’t being detected yet.
Sorry, I forgot say that I have not installed nor enabled the SCM plugin in my server, that’s the cause way I discarted the relation between commits and issues.
Anyway, the same problem happens in around of 200 projects with a last commit date completely different.
Is too difficult for me check all projects, but I’ve checked some of these and in some cases the detected lines already exists before upgrade the server and in other cases the detected lines/classes were added after the issue date (i.e. file commited at 17/Dec - issue date at 14/Dec - real detection at 25/Jan).
The only correct behaviour that I’ve found is when affected lines were added after the custom rules. Other than that I can’t find any common pattern between all affected projects.
