Enforce total warning count to go down

I’m using SonarCloud with Azure DevOps Pipelines. Our solution consists of multiple C# projects. The build produces quite a lot of warnings (~9k). We want the number of warnings to go down. We’re using BuildQualityChecks to compare the number of warnings between our master builds and PR builds. This had been working until some time ago, until I think as “Incremental PR analysis” was introduced and it broke.

I think that the problem we have is the following:

  • SonarCloud/SonarQube no longer analyses unchanged files, as a result the total number of warnings in a PR build are much lower than our master branch → ~7k.
  • SonarCloud/SonarQube doesn’t report about newly introduced warnings in unchanged files, so this means new warnings can be introduced without noticing.
  • Builds for the master branch report all Roslyn + all SQ warnings → 9175
  • Builds for the PR branch report all Roslyn warnings + some SQ warnings → 6867

One possible solution would be to disable “Incremental PR analysis” (how?). I don’t know how much performance penalty that would occur. At least that would mean that SQ/SC report all warnings. Then I’ll have a stable warning count for BuildQualityChecks to analyse. As an added bonus, I might also get SonarCloud reports about new warnings in unchanged files.


Example of warnings reported in the master branch build, but not in a PR branch when file.cs is not changed:

Incremental PR analysis: 3967 files out of 4455 are unchanged.
...
[file.cs](7,14): warning S1210: When implementing IComparable, you should also override Equals, ==, and !=. (https://rules.sonarsource.com/csharp/RSPEC-1210)  
[file.cs](24,6): warning S1133: Do not forget to remove this deprecated code someday. (https://rules.sonarsource.com/csharp/RSPEC-1133) 

Hi,

I understand that new SonarCloud issues can be raised on unchanged files because rules get smarter. Could you help me understand how new Roslyn warnings are raised on unchanged files? Is it also that the implementations get smarter? Or that dependencies change under the covers? Or something else?

You can disable analysis caching, and thus incremental analysis via the UI. I’ll be interested to see if that does indeed result in the behavior change you’re after.

 
HTH,
Ann

Hi Bouke,

I’d be very interested to hear about how you have handled this scenario. We also have .NET projects with lots of warnings, and I want to “encourage” the team to reduce that number. If you have been able to get a working solution, can you share how you have gone about implementing it?

Cheers