We have a C# project in VS 2022 , validated with SonarQube which currently falls with S3776, Cognitive Complexity .
The SonarLint extension is in VS installed and connected to that SonarQube server, synchronising happens successfully .
During the build of the solution on my local VS there is no error, S3776 is shown only as a Warning.
I know that I could change the severity in VS manually, but is it possible to fail the VS build in every case when SonarQube fails (without setting all warnings to error manually within VS) ?
Is there a (semi) automated way to have exactly the same rules, severities, etc in SonarLint which we have in SonarQube?
Ideally we would like SonarLint to tell you whether the new code you are going to commit will result in failing the Quality Gate during SonarLint analysis, and it something we are looking at for the future; we are not there yet, one of the reasons being that there are a few kinds of issues that SonarLint can’t detect yet (you can learn which ones here).
In any case, I am not sure whether failing the build in Visual Studio is the best option to inform developers that their code contains new issues that will fail SonarQube Quality Gate; other possibilities include displaying a pre-commit message in case of new issues or letting the user run an on-demand check. I would love to hear your thought on this.
In the specific case of S3776 (Cognitive Complexity) the issue is well reported by SonarLint and has a “Critical” default severity. As documented here, we map this severity to “Warning” rather than “Error” in Visual Studio exactly to avoid failing the local build. If you wish, you can change that by enabling Treat warnings as errors in your project properties in Visual Studio.
Hello Marco (the forum does not allow me to mention you by name) ,
Many thanks for your answer. Having a pre-commit message would be a nice alternative if the message can be extracted from the last build. If I’d have to wait for a build during a (pre-)commit, that wouldn’t be nice.
If SonarQube is configured to fail for e.g. S3776 (build becomes red and breaks down) then (I think) it would be good if the Visual Studio 2022 build would fail as well. The reason: if SonarQube fails, I need to fix it locally, push again, get an approval on the pull request, wait for the build server. This is a lot longer process. Seeing the build failure locally immediately would be a lot faster - and wouldn’t result in failed builds on the build server (and wouldn’t consume the build server’s resources with the failed build if it fails locally already).
I discovered a possible bug: It’s not possible to change the severity in Visual Studio as well. Even if I do a right click, change severity in the build warning list, nothing happens. The project specific settings file will contain the new severity but this file isn’t loaded anywhere in VS 2022. In addition, in the VS 2022 Solution Explorer you can list the Analyzers for every project (under Dependencies) and SonarLint is not listed.
This process is a big part of the problem. The build and sonar should be running before human approval is required. This is effectively an automated code review, until it passes that, no human needs to spend time on it.
I discovered a possible bug: It’s not possible to change the severity in Visual Studio as well. Even if I do a right click, change severity in the build warning list, nothing happens. The project specific settings file will contain the new severity but this file isn’t loaded anywhere in VS 2022.
When you use SonarLint in connected mode with SonarQube, overriding the severity level locally does not make much sense, because SonarLint synchronizes the severity associated to each rule in your Quality Profile, so the way to override a rule severity is to change it in your SonarQube Quality Profile. In any case, as mentioned above, SonarLint and Visual Studio severity levels are not the same, and SonarLint maps to Visual Studio levels according to this table (as you see, the only VS levels mapped to are: Warning and Info).