I'm using SonarQube v5.0 with MS Build Sonar Runner, C# plugin v4.3 and OpenCover for Code Coverage.
I have two QualityProfiles. 1. With only SonarQube rules. 2. With only FxCop rules.
Using SonarQube rules QualityProfile, everything works fine. Issues are get posted in the dashboard. But when I use FxCop rules only QualityProfile, no issues are get posted in dashboard.
It shows Technical Debt - 0 and Issues- 0.
I have referred to
MsbuildSonar Runner +Fxcop - No fxcop issues are posted to server.SonarDashBoard shows 0 technical debt
where this user faced same issue. But after changing his database Collation with CS_AS, his issue got resolved.
But this is not happened for me. Even after recreating my database with Collation CS_AS (Latin1_General_CS_AS), FxCop issues are not get posted in Dashboard.
NOTE: I can see the CodeAnalsisLog.xml in output directory having 163 warnings.
Also in ProjectInfo.xml, there is an entry for AnalysisResult with ID - FxCop.
Don't have any idea that why FxCop rules are not get posted in dashboard.
Related
I try to configure a whole dev environment with pipelines on AzureDevOps and SonarQube as a static code analyzer.
I added several Roselyn Analyser (StyleCop for instance) and expected to see the issues on SonarQube. Some of them do appear but some don't.
For instance: SA1600 never show up on Sonar.
I added an .editorconfig file which works fine as i can switch off some issues. But whatever the parameter is for the SA1600, it does not appear.
This is quite uncumfortable as my devs would not have the same issues in VS and on Sonar.
How is it possible to configure Sonar to have the same configuration as it is in Visual Studio.
Any idea is welcome :)
We are starting to implement code coverage in our CI process and my task is to examine NCover from this perspective.
Specifically, we have SonarQube and a CI build in Azure DevOps that runs the unit tests and reports the coverage to SonarQube as described in https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-azure-devops/
Currently it works with the DotCover command line tool.
I would like to check NCover. While googling for it I came across this cheerful page - https://www.ncover.com/support/docs/extras/sonar-integration and sure enough I clicked the link to the respective Jira issue - https://jira.sonarsource.com/browse/SONARCS-653 Oops. Closed with Won't Fix.
According to https://docs.sonarqube.org/latest/analysis/coverage/ only VS Coverage, DotCover and OpenCover format are supported. So, if NCover is supported, it would be through the Generic Test Data format or if NCover knows to produce coverage results in one of the other 3 formats.
So far I do not see how NCover can play with SonarQube, but maybe I am missing something here.
Anyone?
Got an answer from an NCover representative. There is no integration between SonarQube and NCover. Full stop.
SonarC# 6.7.1 (build 4347)
SonarQube Version 6.7.1 (build 35068)
Quality Profile: Sonar way (outdated copy) because the current Sonar Way quality profile returns nothing at all.
Running the current MSBuild.SonarQube.Runner (SonarQube Scanner for MSBuild 4.0.2.892) only reports Code Smells. No vulnerabilities or bugs are being reported.
Using https://github.com/SonarSource/sonar-scanning-examples - CSharpProject to test. I've added bugs from the quality profile above into the code but they never get reported. I've tried this with other CS projects with the same results.
Are there any known issues reporting vulnerabilities/bugs for C#? Is any additional configuration required to get this information reported back to SonarQube?
This isn't a known issue, and I couldn't reproduce it using the same versions of the scanner, the C# plugin and a clean install of SonarQube 6.7.1.
Analysing the sample project reported one bug (csharpsquid:S2583, Program.cs line 9), and one code smell (csharpsquid:S1118, Program.cs line 4).
Code Smells, Bugs and Vulnerabilities are all handled the same way by the Scanner for MSBuild - they are all just Roslyn issues with different categories applied. No additional configuration is required.
I'm guessing you've migrated from an older version of SonarQube since you have an outdated SonarWay. However, that shouldn't make any difference to how issues are reported. The rules included in the default SonarWay might change between versions, but you've checked for rules you know are in the active QP.
If you haven't already, you could try installing SonarLint for VS and checking it correctly detects the bugs you've injected into the code.
Other options:
the .sonarqube\conf file will contain a ruleset file showing which rules are being executed by the scanner. Check that contains the expected rules.
the bin directory of each project will contain a XXX.RoslynCA.json file containing all of the issues that were detected during the build. Check they contains the expected issues.
check the console logs for errors or warnings. You could also increase the verbosity of the logged output by passing /d:sonar.verbose=true on the command line in the Begin step.
When I run an incremental analysis on my project through maven, build warner plugin is not called, resulting in an analysis completing successfully even if there are violations.
I have quality gate setup correctly (0 violations) and I have tried configuring sonar sonar.preview.includePlugins with buildwarner plugin in General settings, but without luck - the plugin is still not called in an incremental analysis.
The plugin works correctly with SonarQube 5.1 as it is called in full analysis without problems.
It is the expected behavior. This plugin does not work for incremental analysis for now. But maybe soon. See http://sonarqube.15.x6.nabble.com/Sonarqube-and-Build-Breaker-Plugin-td5034703.html
I am upgrading from sonar 3.3.2 to sonarqube 4.5.1. I am comparing one project in each version. Everything looks good except the technical debt and the unit tests.
Why is this happening?
Here is the technical debt in 3.3.2:
Here is the technical debt in 4.5.1:
In the past when I get 0 TD & 0 Issues, it has been because sonar runner did not analyze the appropriate files either because the sonar.language was wrong or the exclusion patterns resulted in a few/no files to analyze. Try drilling down to see which files got analyzed by clicking on issues "0"
I would also check the activated rules to see if the rules that found issues got deactivated. To do this, check the logs for the quality profile sonar runner used then go to Quality Profiles on your sonar site & check that profile to make sure it has activated rules