I.e, on the main branch, only code newer than 2 days is considered.
We had a merge request that made some changes, including switching from Java 11 to Java 17. It had a passing pipeline, so we merged, and bam! the analysis fails on the main branch:
As you can see, the new code is correctly detected (it says “New code: Since 2 days ago”, and only 9 lines are considered as new. However, I get 10 code smells, and they are raised on totally different and much older code. Those smells are typically related to Java 17 (Replace this usage of ‘Stream.collect(Collectors.toList())’ with ‘Stream.toList()’).
So my question is: Does SonarQube ignore the new code definition when it’s detecting a java version change? Is it because those issues are on old code but are considered new? And why was it not raised in the passing merge request analysis?
Thanks. This is a tricky situation where issue backdating doesn’t kick in.
On the first analysis of a project or branch
When the rule is new in the profile (a brand new rule activated or a rule that was deactivated and is now activated)
When the analyzer has just been upgraded (because rule implementations could be smarter now)
When the rule is external
The rule is technically not new to the profile or smarter, its logic just figures out that it should raise an issue (as it always would have) because Java 17 is being used.
I hope you can forgive us those 10 issues this time, and I’ll flag this for attention by moving it to the Producrt Manager for a Day category.
To be perfectly straight, I find this awesome. I don’t mind putting out another MR to fix this, it’s 10 code smells out of our codebase. I just wanted to understand the inner workings and find some documentation.
