New Issue not shown on "New Code" tab

  • which versions are you using?
    ** SonarQube 9.6.1 Enterprise
    ** Checkstyle 10.3.2
    ** Findbugs 4.2.1
    ** PMD 3.4.0
  • how is SonarQube deployed: zip

Hi,
we are following the “Clean as you Code approach” and therefore only look at “New Code”.
“New Code” is defined by using the “Master” as reference branch for each analysis on feature branches. For the “Master”, “New Code” is defined by “Previous Version”, I hope this is how it should be done.

Now a new issue came up on the “Master”, shown on the “New Code” tab:

Remove this unused “IPAD” private field.

This is a valid issue, as the only usage of this field was deleted recently.

On the branch where the issue was introduced, the branch analysis shows no issues on “New Code”.
The issue was shown, but only on the “Overall Code” tab, which is ignored by the quality gate and the developers as well.

Is this the expected behaviour?

Note: We changed our “New Code” definition for branches recently, so at the time the relevant commit took place, “New Code” was still based on “Previous version” for branches as well. But I would expect this to be irrelevant, as after the definition change, the branch was analysed again. In this analysis the reference was the “Master”, still the new issue didn’t show up on the “New Code” tab.

Thanks!

Regards,
Carsten

Hi Carsten,

Welcome to the community!

Actually, it is.

So you’re only looking at the lines that are changed from main. When you deleted the only use of IPAD, its declaration wasn’t changed. It was still, legitimately “old” code in the branch, given the way you defined new code (“show me issues on lines that are different from main”). Then when the issue showed up in main, it was with a different definition of new (issues raised since the previous version) and so it showed up.

I know this isn’t a satisfying explanation. Unfortunately, it’s a tricky issue. But does it make sense?

Also:
:warning: Make sure you upgrade to SonarQube v9.9 LTS soon, not only to benefit from our Best LTS Ever™, but because soon we will systematically ask users to upgrade when they ask questions about earlier versions of SonarQube, which are now considered unsupported. :smiley:

 
HTH,
Ann

Hi Ann,

thanks for your explanation! I understand it but yes, it is not really satisfying.

I thought when we use a reference branch, “new code” would mean “show me issues which are not found on main”. But I expected the branch analysis to check all lines.
If it only shows issues on changes lines, its result would be the same as for the PullRequest-Analysis, right?

So which settings would we need to find issues like this before merging to main, but still only seeing issues which were introduced on this branch?

Thanks!

Regards,
Carsten

Hi Carsten,

Yes, it does. I think if you check the branch’s Overall issues, you should find the one in question.

I understand. To be honest, reporting properly on new issues has proved to be a harder topic than it maybe seems. We’ve had to use some heuristics, and the one that’s impacting you here is “only issues on code changed in the New Code period are ‘new’”.

You probably want to use previous_version for your branches as well.

 
Ann

Hi Ann,

yes, on the “Overall” tab the issue is shown in the branch analysis. But for “Clean as you Code” I should ignore the “Overall” tab, so I expect the “New Code” tab to show me everything I need to now.

So if I understand correctly, there is no difference on the “New Code” tab between a Pull Request Analysis and a Branch analysis with using the master/main branch as reference for “New Code”?

We did, but it lead to issues showing up on “New Code” which were not related to the current feature branch. In addition, these were often already closed as “won’t fix” in the master/main, but as this status is not synced between branches, they were still shown in the feature branch. This lead to a lot of confusion and frustration, so we decided to switch to the reference branch as definition for “New Code”.

Yes, the master/main should be clean, but in reality it often enough is different, especially as new issues can only be marked as “won’t fix” in the Pull Request Analysis where not all of them are shown. So some issues have to be introduced to the master to be closed and others are added by mistake as the developers didn’t recognize them as new issues in the branch analysis. Until they are fixed, every branch will inherit them by integrating the master, leading to unnecessary findings in those branches.

So as long as the issue status is not synced between branches, “previous version” doesn’t seem to work for us.

Maybe it is a problem, that we use “won’t fix” quite a lot. We are working on a legacy code base, 1.4 million lines, up to 20 years old, so a lot of code smells pop up as soon as you touch the old parts. These are often closed as “won’t fix”, as fixing them would be too expensive or risky.

Regards,
Carsten

Hi Carsten,

No, I don’t believe so.

Regarding the ongoing sync of Won’t Fix issues between branches, I recognize your frustration. I don’t believe addressing it is high on the list right now, but I’ll make sure the product manager sees this thread.

 
Ann

Hi Ann,

thanks for your understanding for forwarding this issue. I am not the only one waiting for this feature:
https://community.sonarsource.com/t/dealing-with-false-positives-wont-fixes/35173
https://community.sonarsource.com/t/new-branch-analysis-picking-older-codes-and-issues/45761/5
https://community.sonarsource.com/t/issues-marked-as-resolved-wontfix-in-master-branch-are-still-shown-as-issues-in-other-branches/64180

I have to admit, that it is mentioned in the documentation. At Defining new code it says

Any changes made between your branch and the reference branch are considered New Code.

What confused me was Issues with

Unmatched “raw” issues are considered new

I somehow mixed up “New Code” and “New Issues” in my head. So in combination it means “show me issues, which are not found on main, on lines that are different from main”. Am I right?

Btw. on Branch analysis it says

Issues can be synchronized between branches if you’re using the Reference Branch new code definition. When using this new code definition, any new issue in the reference branch that comes from a feature branch automatically inherits its attributes (type, severity, etc.) from the feature branch. A comment is added to the change log of the issue on the branch: The issue has been merged from '<branch-1>' into '<branch-2> .

I guess the status is none of these attributes? Maybe this could be made a bit clearer here.
I cannot see the mentioned comment at my issue in the master/main.

Thanks!

Regards,
Carsten

PS: We are working on migrating to SonarQube 9.9.

1 Like

Hi Carsten,

I suggest not taking these threads as a reference. They look to me either quite old or about different problems.

I somehow mixed up “New Code” and “New Issues” in my head. So in combination, it means “show me issues, which are not found on main, on lines that are different from main”. Am I right?

Using the “reference branch” as the “New Code” definition for branches should help avoid surprises. I’m curious about the fact that, when using a “reference branch”, you can discover new issues in the old code of your branch. It might happen in a few cases when an issue is triggered by some changes applied somewhere else in the code. For example, you may remove all uses of a variable which would create an issue where the variable is declared.

So if I understand correctly, there is no difference on the “New Code” tab between a Pull Request Analysis and a Branch analysis with using the master/main branch as reference for “New Code”?

You may see a few differences between a Pull Request analysis and a branch analysis because of the way the New Code detection is technically implemented. In Pull Requests we have clear diff information, whereas in branches we still have to technically rely on a date for the start of the New Code definition.

I guess the status is none of these attributes? Maybe this could be made a bit clearer here.
I cannot see the mentioned comment at my issue in the master/main.

Won’t Fix/False Positive status is part of the attributes that are synchronized. We could indeed make it more explicit in the sentence you quoted. Currently, this is explained here.

Chris

Hi Chris,

That’s exactly what has happened in our case. So it seems like we are already doing it right, and just came across one of the (hopefully) rare scenarios, where an issue is not shown on the “New Code” tab.

Thanks for clarifying this! This might indeed help a lot.

Regards,
Carsten