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.
Related
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.
I have enabled sonar lint plugin to my IntelliJ IDE for capturing code violations during my development. i have connected to my remote SonarQube server for rules binding.
Plugin capture rules for major, minor issues and not capturing critical rule violations on my local IDE.
my binding updated to latest rules , but critical issues are not getting picked up by the intellji plugin.
dont know how to fix this on my machine, or should i need to raise a bug?
EDIT
All critical issues are not getting reported.
sonarqube reporting below critical issue
An 'int' is expected rather than a String
but in intellji sonarlint plugin, the above issue is not getting reported.
I have read all of the threads about SonarLint not being in synch with SonarQube, but it's just not clicking.
I created a simple Maven project to test SonarLint & SonarQube. I added the sonar-maven-plugin to the project and then ran mvn sonar:sonar.
The project was uploaded to SonarQube. When I looked in SonarQube, I see that it shows squid:S2699 (junit test doesn't have an assertion) as a blocker.
However, in eclipse, there is no such issue shown by SonarLint.
I purposely chose this one as it's not a PMD/FindBugs/Checkstyle issue.
I have verified that squid:S2699 is active on the server. Obviously it is, because SonarQube displayed it.
There is only 1 Quality Profile: SonarWay.
Edit: I am in connected mode.
Does anyone have any idea why?
I am using:
Eclipse Neon.3 Release (4.6.3)
sonar-maven-plugin 3.0.2
maven 3.3.9 (the one embedded in eclipse)
SonarLint 3.2.0.201706271328
SonarQube 6.3 (build 19869)
Here are the screenshots as proof.
It seems your test file is not treated as a test file, but as a source file. I say this based on the kind of errors that are reported (remove unused variable) and the kind of errors that are not reported (no assertions).
As you might know, different rules are applied to sources and tests.
SonarLint decides whether a file is a test file or not based on the Test file regular expressions preference, which you can find in Window / Preferences / SonarLint. The default value is **/*Test.*,**/test/**/*,
this seems to work well in a wide range of cases, and looking at your screenshot, it should work for yours too.
So first of all verify this setting.
If the value is different from the default,
I suggest to change it back to the default as a sanity check.
Then you can tweak the value according to your needs.
It's also good to verify that my theory is correct about SonarLint treating the file as test instead of source, by inspecting the SonarLint Console:
In the Console view, click on the Open Console dropdown, select SonarLint Console
In the Configure logs dropdown enable Verbose output
Trigger an analysis of the test file (make a change and save the file)
You should see output like this:
[
baseDir: ...
workDir: ...
extraProperties: ...
inputFiles: [
/path/to/your/test/SonarProofTest.java [test]
]
]
The [test] at the end of the filename indicates the file is treated as a test file. If it's not there, then the file is treated as a source file.
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
Since we updated to SonarQube 6.2 it seems code coverage plugin got merged in the core.
It shows red flags everywhere and I can’t find how to turn it off, we do not use code coverage.
You don't specify what language(s) you're analyzing. I'll assume Java and/or JavaScript. Starting from 6.2, SonarQube supports "force coverage to 0", which marks as uncovered executable lines in files that don't show up in any coverage reports. (That's assuming the underlying code analyzers support the feature, and Java and JavaScript already do.) The purpose is to have a more accurate picture of what's missing when you actually are using unit tests. Without this feature, it's impossible to tell whether a file that's omitted from coverage reports is missing because it has no executable code or because there are no tests on it - even when there should be.
Since you're not using unit tests (really?) you can exclude all the source files in your project from coverage calculations via the UI: Administration > Analysis Scope > Coverage Exclusions. A pattern value of **/*.* ought to do it for you.
Code coverage feature is in SonarQube misleading. To turn this off:
Under Quality gates create new or copy existing profile.
There delete Coverage metric
SonarQube Version: 9.2