we use the Sonarqube extension in VisualStudio where we bind our projects to the projects in Sonarqube. We recently made a huge step to have finally a warning free build so we activated the feature TreatWarningsAsError in our visual studio projects. Since then, all Sonarqube findings get red squiggles which makes it unusable as we cannot fix all sonarqube issues at the moment. But with the red squiggles for Sonarqube issues its impossible to work with as they cannot be distinguished from real compiling errors.
Is there any way to fix this issue and have sonarqube issues treated as usual and only show compiler warnings as errors?
Hi there, @frd, and sorry for the delay in answering.
I’m not exactly sure I understand what you are trying to achieve here.
Is the problem that you would like to “hide” our findings?
More precisely, what would you expect to be able to do with respect to our issues?
Hi Denis, thanks for coming back to this.
I do not want to hide the findings and its very useful to see them in the code. But there is a big issue when sonarqube findings are treated as errors as it pollutes the code editor with many red squiggles which which makes it hard to develop on big code bases with a lot of legacy code where you can’t fix all sonarqube findings at the moment. We make use of the quality gates and therefore we still have many findings in our code base. The quality gates are a USP of Sonarqube, but I don’t think that the sonarlint plugin has a good implementation for this when it just defines every finding as error.
In my expectation, the findings by the sonarlint extension should not be affected by the project setting “TreatWarningsAsError” or it should properly respect the quality gates and only mark new code with errors, but not existing code. Existing code should be visualized in the same way as TreatWarningsAsError is not activated.
The level of our findings is mapped to the severity we attach to the rule. You could also, in theory, change that using local .editorconfig, but I would imagine that would be cumbersome to maintain.
If your problem is indeed about the amount of distraction that “past debt” creates, I think you might find the option to “focus on new code” would help, as it should reduce the amount of active findings to what you are working on at the moment. For Visual Studio it does require to use connected mode to work, so you will want to ensure your project is bound.
We use the New Code feature on Sonarqube and it works fine on Sonarqube. The build will only fail if the “New Code” compared to reference commit has any issues. But the extension in VisualStudio does not adapt this “New Code”-Setting and just marks everything as Error, even issues which are accepted on Sonarqube because its legacy code.
We also have our Solution properly connected to our Sonarqube instance.