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
Related
It has been cleared here that from Sonarqube version 6.2 that coverage reports are merged and there won't be separate unit and integration coverage report anymore.
We still interested to have these two coverage reports separately. So, We have three sonar projects: unit-tests, integration-tests, whole-project(which is responsible to create overall coverage report)
Problem: All source files are analysed in all three projects. Since the number of files are too many, it takes several minutes to perform the analysis.
Question: Is it possible to turn off sonar issue analyser somehow in a project? It is desired to report only test coverage in the the first two projects(unit-tests & integration-tests) without analysing all files, and then run the issue analyzer only on the last project(whole-project). It could help us to analyse all files once instead of three times.
Additional info: We use sonar gradle plugin version 2.6.2 and sonarqube version 7.4
SonarQube/SonarCloud main responsibility is informing users about issues. Displaying code coverage is just an additional feature. It means there is no flag/parameter which allows you to do it.
Luckily, there is a workaround. You can create empty quality profiles, and use them to scan those two projects (unit-tests & integration-tests). You will get 0 issues because there are zero rules enabled.
The following feature request should be interesting for you: Making test coverage measures mode useful. Feel free to vote on it.
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.
We have two Environment of Sonar having versions (5.6 & 6.3).
We have set up all the sonar quality profiles,types,rules,severity identical in both environments.
But when we do analysis from both versions on the same repository, we are getting difference in the sonar analysis and its issues severities.
Please help us to find where the issue may persists.
Generally speaking:
only because you have the same version of SonarQube, does not mean that you are using the same Plugins.
Even tough the plugins have the same rules, they are also differ from release to release. Plugin developers find bugs in the rules, or there is a big change of severity, and movement from category "bugs" to "code smell"
so, as long as your server is not running the same plugin versions - you can not compare the outcome of those two!
Having a look to our build logs, I can see this warning:
build 31-Dec-2015 10:37:39 [WARN] [10:37:39.896] Ability to set quality profile from command line using 'sonar.profile' is deprecated and will be dropped in a future SonarQube version. Please configure quality profile used by your project on SonarQube server.
Even if I can easily understand why it could be deprecated, I have an issue with that. We have a single SonarQube installation for all our teams. Each team must be compliant with a given Quality Gate but can define its own profile, depending on the needs. We are working with git branches. We have "static" branches such as master and develop, but also feature and bugfix branches which are also scanned (to insure code quality before merge). Entries in sonar are created also from command line
Dsonar.project.branch=${bamboo.planRepository.branch}
Which helps us to get one sonar entry per development branch.
Issue: Each time we create a feature, not having the command line will force us to go to Sonar and manually change the profile.
Do you have any suggestions, ideas, which may help us ?
Thanks
I have a similar problem with the potential deprecation of this feature. We have too many projects to be managing this administratively in sonarqube.
The best approach for our site is to allow the teams to select an approved profile using setting in the maven pom.xml.
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.