Is there a way to report issues only on new code?

SonarQube Server / Community Build
1

Using Sonarqube developer edition 8.9 (build 43852)
Sonar scanner 4.6.2

There are a number of rules available which report a large number of issues for us (e.g. java:S6212 reports 16K issues). It is not practical for us to take on a massive effort to clean those out. Also, it is not “fair” in some sense for our code quality metrics today to look worse than they did a month ago because a new rule was introduced.

In a separate ticket, I brought up the idea of simplifying the effort to deactivate problematic rules Help or NFR: Better way to deactivate rules that are active in SonarWay profiles - #4 by Colin_SonarSource

Ideally, though, I would not want to deactivate the rule from the profile, I would simply like a way to have it reported as an issue for pull request analysis/decoration and not for branch analysis. In that way, we can keep the situation from getting worse until we have the time to clean up the technical debt on the main branch. And meanwhile, the overall metrics reported are more appropriate.

2

Hi,

This is exactly the problem the Clean as You Code methodology was designed to fix. The idea is - just as you’re asking - that you focus only on new code. The issues on old code are raised and can be considered “in the backlog” - when you have to work on that code again you’ll deal with them. In the meantime you should only pay attention - as you suggest - to pull requests.

 
Ann

3

We are using the SQ metrics of our branches to measure project quality over time/releases. Having it spike up implies we added a bunch of “bad” code to the present release, but the rule is mainly flagging technical debt from older releases. I realize that this could happen for a number of reasons due to changes in the rules/profile, I am just looking for a way to do apples-to-apples quality comparisons between releases.

4

Hi,

This suggests to me that you’re using “overall” metrics as your yardstick rather than “On New Code” values. We recommend the opposite. That allows you to focus on keeping your new code (all the code - and only the code - touched since the last release) clean. Then issues added on old code are reduced to what they truly are: background noise.

 
Ann

5

We use both. “New Code” is defined globally as “Previous Release”. SonarQube

I am pretty sure (but not 100%) that the issues reported by java:S6212 had many classified as “for 7 years” or “for 8 years” etc. on files that had not been touched in this release. I cannot tell any more today because we recently touched almost all the files to comply with java:S1120