I see 26,253 warnings in MSbuild log with SonarScanner (Red marked). It includes 558 compiler warnings, rest are from the code analyzer.
But, I see only 16,396 issues in SonarQube (blue marked)
Why there is huge difference of around 10,000 issues, why are not those issues reported in SonarQube !!
There are three four (thanks #Julian) possibilities here:
~10k issues in your project have been "resolved" False Positive or Won't Fix. Okay, this volume of FP/WF issues is unlikely, so on to
You have set some exclusions which filter out some issues. This is possible, but 10k seems a bit high for that, so...
The number you're looking at is the total number of SonarC# issues, plus compiler warnings, plus (insert some other checker run automatically during the build here), but only issues that correlate to Rules active in your Quality Profile will be reflected in SonarQube
.cs files outside the project base directory may be excluded automatically by the SonarQube Scanner for MSBuild
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.
SonarQube Quality Profiles are not being used during the sonarqube scan:
We have sonar tasks installed and enabled for build definition what we are seeing is that the quality profiles are being stopped for one build run and it is again started using the quality profiles for the next run automatically. We are consistently seeing the same behavior for the alternate build runs.
Image where we can see the profiles are stopped and started:
What you're seeing is the result of a bad configuration somewhere. You indicate your comments that along with the toggling of profiles, you also see large swings in issue counts
as most of the file types get excluded from analysis resulting in very few issues reported.
So let's break this down:
The profile events you're seeing simply record/reflect the changes in profile use from one analysis to another. If I have a project with Java and JavaScript, the first analysis will use the default profiles for that language. Then, let's say I use the deprecated property sonar.language to restrict analysis to just Java files and analyze again. Since JavaScript is no longer found in my project, the default JavaScript profile will not be used, and a profile event will be recorded.
That seems to be what you're seeing in your activity log.
So now to the detective work: why is this happening? First, this swings back and forth. That indicates configurations set not at the project level (in SonarQube itself) but properties that are only sometimes passed during the analysis, or some other analysis-side circumstance. There are a few possible causes which you'll need to investigate independently:
sonar.language - if this deprecated property is used during analysis, it will limit the by-default multi-language analysis to a single language. It could be in your properties files or passed on the analysis command line -Dsonar.language=foo
exclusions - exclusions are difficult to set properly from the analysis side, but this can happen
improper/incomplete checkout - is it possible that only part of your project is checked out?
In investigating this, you should be aware that analysis-side properties can be set at two levels; at the individual project/analysis or in the global scanner configuration.
I'm guessing that your CI system has multiple slaves and languages are dropped - or not - from your project depending on which slave the job lands on that night.
I was experiencing a similar problem and I believe I have tracked down the root of the issue for us. Capturing the source code and properties used during the build, I was unable to find any discrepancies in sonar properties or source code collected, as suggested in the previous answer.
Our solution we were trying to analyze with SonarQube has a few C# projects that are part of an external core solution, which is shared between several components. Compiling any one of these other components requires that core be compiled first. I believe the issue lies in that when compiling my component to be analyzed, MsBuild would sometimes rebuild some of the projects included in core. Depending on if they were rebuilt or not, the number of projects and files (and hence issues) would swing wildly in one direction or the other.
By enforcing MsBuild to clean my component solution before compiling,
MsBuild.exe MySolution.sln /t:Clean,Build
I ensure a consistent set of projects are built and analyzed by sonarqube. I am 30 builds in with this new approach and I have no more flopping back and forth between using and not using a quality profile.
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.
I have been using sonar for over 4 years for Java projects we have created.
Currently, we want to fail the build if some metrics cannot be met. Thus, I installed Build Breaker plugin and re-run the build cycle, without any issue. Then I modified quality gates to contain "'Comments (%)' rule to for 'is less than' check of '20' ( threshold for warning), '10'( threshold for error) " as attached in:
However, after those definitions the projects failed to build. Although all files seem to have enough comment (from 28 % to 77 %) , as in image below,
While in main screen it is shown as 0%
I could not find any log, comment or information on how this can happen (in sonar.log or mvn -X ) and as far I searched , no one encountered this issue.
Did anyone encountered this problem, or have any idea why this can occur? My SonarQube version is 5.6.7, Build Breaker version is 2.2 (downloaded from github), maven version is 3.0.5 and JDK 8.
When defining your Quality Gate, you selected the option "over leak period". So what counts the variation of the % of comments in your current leak period, which is the version 1.4.1.
What you see in the screenshot with the perc. of comments per file is the absolute measure.
You might want to uncheck the option "over leak period".
Note that the way measures are displayed was improved in later versions of SonarQube.
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