How to handle issues on unchanged lines?

SonarQube Server / Community Build
,
1

Hi,

maybe somebody has an idea how the handle the following scenario (using SonarQube Enterprise 2025.1):

We are working with feature branches and a quality gate checking new code. These branches are analysed with a merge request analysis, using the master as reference branch for new code.
The master itself is then analysed with a branch analysis, new code is set to “previous version” here.
With this process, we should be able to identify new issues on the branches, can fix/accept them, and have a green analysis on the master.

But there are faling master analyses, because of new issues on unchanged lines:

  • last usage of an import, parameter or private method was removed.
  • deprecations because of dependency updates.
  • too many levels of inheritance because of an dependency updates.
  • etc.

(1) These issues cannot be found by a merge request analysis, as the affected lines are not contained.
(2) They as well cannot be found by a branch analysis using a reference branch, as the affected lines are not contained in new code.
(3) They can be found by a branch analysis with some other new code definition.

When using option (1) or (2), the issue status “accepted” is as well applied to the master on merging the branch.
When using option (3), the issues will occur on the master as well and have to be accepted again (after a failed analysis)

So we can either choose to not find these issues, or we can find but not accept them, both leads to a failed analysis on the master.

In an ideal world (i.e. having a clean code base) we should probably use option (2) and add “overall code” to our quality gate. We would then find these issues and their status would be applied to the master as well.
But sadly our code base is far from ideal (very old and huge), so there are many existing issues in overall code. So adding overall code to the quality gate is not an option.

It would be great to hear some suggestions on this! Thanks!

Regards,
Carsten

2

Hey @Carsten_HB

We struggle with this at Sonar as well, facing the exact same issue, and it’s a matter of getting this roadmap item prioritized.

Now, how do we deal with it when it happens? I think we end up with a failed analysis on master that we have to run behind and cleanup (create another PR fixing those issues, or accept the issues for now). Not great.

I’d like to know – how often does this affect your team? It’s not a lot of rules that behave like this.

1 Like
3

Hi @Colin ,

thanks for your answer.
We are working with 7 teams on a monorepo, so a failing analysis on the master affects the whole department. I don’t know how often it happens, but the developers keep on complaining about it. In my opinion this is a major issue for the acceptance of SonarQube as a tool.

We have ~4 analysis on the master each day, additionally ~3 each day on older release lines, which is ~35 in total per week. So the chances are high to face this issue regularly.

Regards,
Carsten

4

It would be helpful to maintain an ongoing list of Rule IDs where this occurs, as we currently don’t track this information. Keeping such a list would allow us to better understand the full scope of the issue and identify opportunities to adjust rules where necessary (some there’s no hope, like unused import, but others might be different).

5

Something funny that we’ve realized is that SonarQube Cloud doesn’t have this same problem…

So that’s news. I’ve reported that internally to see what’s going on.