Sonar Qube not failing Pull Request build when file change indirectly causes a different code smell

versions:
SonarQube: 8.6.1.40680
Using AzureDevops for builds/current scanner/analyzer: 4.19.0

This is an issue with c# code. We currently have a “perfectly” clean project - i.e. no problems at all, no code smells, completely clean:

If I make a PR that removes let’s say a line of logging:
_logger.LogInformation(“test log”);

and because I remove that, the using statement:
using Microsoft.Extensions.Logging;

is no longer required, the PR build/sonar builds fine even though all my quality gates say no code smells on either new or existing code:

but once I merge this code into our develop branch, SonarQube fails on code smells :

I believe the issue is that “New Code” is only analyzed for lines of code that were modified, but in this case those modified lines have caused an indirect break that should fail in the PR before it is merged.

I don’t have a workaround - ideally I’d make it so that every build is treated like my main “develop” branch build instead of doing any “new code” analysis at all.

Hi jaz,

Welcome to the SonarSource Community!

I assume you are using Developer Edition here. All PR analyses are measured against New Code Quality Gate criteria. I can’t tell what is going on based on your screenshots. Were there additional commits to develop prior to the PR merge? If so, this is the intended behavior. SonarQube is analyzing the code in PR branch before the merge, not a preview of what the develop branch will be after the merge-commit.

On a side note, you should consider lowering the criteria for Code Smells in your Quality Gate. What you have setup requires developers to write perfect code and will frustrate your developers in the way you are experiencing (i.e. a single minor Code Smell caused by a merge is failing my Quality Gate). We recommend requiring a Maintainability Rating of A on New Code. This will allow a small amount of technical debt but will catch really messy code.

Cheers,

Brian

thanks for the response Brian! a few followups:
-yes, using Developer Edition
-yes, there is a lot of commit history in develop prior to the PR merge - so sounds like SonarQube is following the intended behavior

I can relax the code smells criteria, but we still experience issues where removing/changing code in one part of the file can also indirectly reduce the code quality to a B for example as well so it won’t catch all the cases. Is there still any way to build a PR branch w/ the same rules as the develop branch? (I have tried experimenting with the “new” code settings but that still doesn’t make much difference since PR’s are only looking at newly changed lines).