SonarQube Developer Edition branch and pull request "new issues" aren't new

Hi, I’m currently evaluating the Developer Edition. I’m hoping to get some clarity about how new issues are judged in branches and pull requests.

I’ve noticed that most of the “new” issues in branch and pull request scans are ones that have dates quite a bit older than the date of any of the new commits. I think this is happening because of shifts in the code base for older pull requests and for branches that have gotten some distance from master.

Given that the scanner can tell that an issue has been around 1, 2, 10 years ago given VCS blame info, I’m wondering if there is a way to shift the “new issue” filter to only show things that have new blame data?


The computation of “new issues” doesn’t rely only on whether it’s located on a new line of code.
It most situations, SonarQube will compare the issues found in the branch or pull request with the issues found in its target branch. Issues that aren’t in the target branch will be considered to be new issues.

The reason is that there can be cases where modifying a line will create or fix an issue somewhere else.

There are some exceptions to this. For example, if the target branch hasn’t been analyzed in SonarQube, the new issues will simply be the issues involving one of the new lines of code in the branch.

We are actually working on the branch support right now and we will probably start relying more on the new lines of code to figure out what issues are new and were introduced in the branch or pull request.

1 Like