In our project new code on feature branches/pull request is defined as compared to main branch. But more often than not, the SonarQube quality gate will fail on old issues, whereas it should only fail on new code. Upon inspection, the issues are not highlighted in yellow.
Sometimes this happens on old code in files that I’ve worked in (which would be a bit understandable, but still the blame information should prevent this), but it also happens in files that haven’t been touched for a long time.
As you can see, no yellow highlight, so this is not actually new code.
Blame information:
So this code dates from 2018. I’ve blurred out some potentially identifiable information but the issue should be clear.
When it’s only a few ‘old’ issues, it’s easy to ignore them and manually verify that there aren’t any issues with the code that you actually wrote. But when it’s 704 issues, this is not feasible.
I don’t know whether this is a bug in SonarQube, or I just don’t understand how it works. Any help would be greatly appreciated.
We do indeed rebase our feature branches and actually I noticed the problems referenced in those two tickets a few days ago. I’m glad to see that they are fixed or expected soon. But I think that they are not relevant to what I describe.
These fixes are about code that is actually new, but not detected as new code. The problem I’m describing is (almost) the opposite: issues on old code (that hasn’t been touched in years) suddenly affect the Reliability and Maintainability Rating of a feature branch.
To be clear: the old code is not detected as new code (no yellow highlighting, not included in lines to be covered), but the issues raised by the old code are reported as New Bugs or Added debt.
Okay, well that’s a bit top-of-mind for me at the moment, so I wanted to ask.
Can you characterize or give a list of the rules in play here? Because it’s certainly possible to have new issues in old code when some other line is changed.
As an example, let’s say I have a class with only one reference to a member variable. That variable declaration was last edited in 2018. Then in refactoring I delete the only use of that variable. The next analysis will raise a brand new “unused variable” issue on that 2018 code. This is just one of many such scenarios. Does it sound relevant?
No worries. By mentioning it, you did provide a solution for another problem that I recently encountered but hadn’t had the time to investigate. So thank you for that.
As for your example, that does clarify things a bit, and it could explain some of the issues that I encounter, but not all of them. For example, I get ‘Remove this unused import’ issues in classes that I haven’t touched. In one case, the code that used the import was removed in June 2021.
When I look at my main branch (named ‘development’), the issue is there (first issue in this screen shot):
When I look at a feature branch that was started 14 days ago, and filter issues on new code, that same issue also shows up (first issue in this screen shot):
In the main branch, the issue was raised 4 months ago. In the feature branch that has changed to 13 days ago. But it’s the exact same issue, in a piece of code that I haven’t touched, called or referenced in my feature branch.
The same thing goes for the other issues in that second screen shot, and most (if not all) of the 704 issues on new code that SonarQube reports. An exhaustive list of all the rules in play would be too long, but here are a few of them (ignoring the ones that you can see in the screenshots above):
Subclasses that add fields should override ‘equals’ (no fields were added - or moved - to any subclass in the feature branch)
@Deprecated code should not be used (no new code was written that uses deprecated code, nor did I add the @Deprecated tag to existing code)
‘throws’ declarations should not be superfluous
Another thing I noticed: if there are 704 new issues in my feature branch, the total amount of issues (not just new code but all code) should also increase by 704 (minus the issues that I fixed along the way). But the total amount in the main branch is 4168, and 4161 in the feature branch. And I’m certain that I didn’t solve 700 issues.
The issues are appearing as part of overall code on the main branch. On the feature branch they are flagged as New Bugs, New Code Smells etc. on the overview page (see first screen shot of my first message). On the Issues tab they show up when filtering on new code (you can see the filter on the 3rd screenshot of the 5th message in this thread).
We use Previous version on the main branch and Reference branch on all other branches
Yes, we use GitLab
Not in this particular case. We have noticed issues when rebasing, but the problem I’m addressing in this thread happens without rebasing.
As a side note, I had this problem happen in another feature branch. Not knowing about SONAR-14929 or SONAR-15697, I rebased onto the main branch just to make sure that everything was up to date. After the rebase, Sonar didn’t detect any difference between main and feature branch, which I think is the problem addressed in either SONAR-14929 or SONAR-15697 (being relatively new to Sonar I don’t understand the difference between the two tickets). This also made my problem disappear: no old issues were flagged as new on the feature branch.
Thanks a lot for sharing this information with us.
From what you’re describing, your issue does not seem related to SONAR-14929 (issues are not considered new after a merge happened on a branch using reference branch as its new code strategy) or SONAR-15697 (issues identified as new in SQ are no longer new if the branch is re-analyzed after a rebase on to the main branch took place).
However, the solution we’re proposing for these 2 issues may help. It consists on changing how we identify lines on a branch as new when using the reference branch strategy (we will now use git diff), and based on that only the issues appearing on those new lines will be considered new.
You can follow the progress of the fix here. I’ve linked your post on it as a reference.
Are there any steps you could share with us in order to help us reproduce your scenario?
A few things that could be useful for us to understand how to reproduce your scenario:
Let’s focus on one of the issues which are wrongly flagged as new.
You can select whichever you want. Its issue key will be available on the URL if you click on it: {SQ-URL}/project/issues?id={project-key}&open={issue-key}&resolved=false
Then you can query it on the SQ database by doing
select i.kee,
i.line,
i.author_login,
i.created_at ,
i.updated_at,
i.issue_creation_date,
i.issue_update_date
from issues i where i.kee = '{issue-key}'
Hi Belén,
I can’t find out how to send a direct message. When I click your (or indeed any) avatar, I don’t see the direct message icon. I did reach trust level 1 yesterday so I think I should be able to send DM’s? Or maybe there are some other restrictions on my account?
Hi. I’m facing a very similar problem. I’d like to know if you have any new information.
Some issues are being detected as “new code” on several different projects. Although Sonar detects it “2 days ago”, the last changes in these classes are more than 4 years old.
I’m using Version 8.9.6 (build 50800). We’ve began noticing the problem after implementing the workaround described in False positive on S1206 - #6 by michele.lorenzini (SONARJAVA-4023). We’re not sure if this issue is solved on version 8.9.7. However, we are not sure that the new code problem is related with the workaround (add a path to vm.jar on sonar.java.libraries), since the problem still exists after undoing it.
both @ganncamp and @Belen_Pruvost seem to agree that this issue is related to how Sonar compares code on a feature branch with main branch. They and I could not be 100% sure because I couldn’t consistently replicate the issue, but all signs point in that direction.
The way that Sonar does the comparison has been changed in version 9.3 (you can find a more detailed description in the issues linked in @ganncamp 's first reply on this thread). I have literally upgraded my SonarQube instance a few minutes ago, so I haven’t had time to check for improvements on my end.
I realize that this isn’t terribly useful information. I would suggest reading the descriptions of the issues in @ganncamp 's post, and see if they resemble your specific situation. If they do, an upgrade to 9.3 should solve your problem.
