I am using SonarQube 5.1 with MSBuild SonarQube Runner for our quality inspection. Currently SCM support is not there although I have already installed TFVC plugin. I get the following log from the analyze process
07:18:22 07:18:22.352 INFO - Sensor SCM Sensor
07:18:22 07:18:22.352 INFO - No SCM system was detected. You can use the 'sonar.scm.provider' property to explicitly specify it.
07:18:22 07:18:22.352 INFO - Sensor SCM Sensor (done) | time=0ms
Then I set the following properties in the general "sonar.properites" file loacated in \sonarqube-5.1.2\conf folder (which I might be doing wrong)
sonar.scm.enabled=true
sonar.scm.provider=tfvc
sonar.tfvc.username=myTFSusername
sonar.tfvc.password.secured=myTFSpassword
I guess these properties should be set in the "sonar-project.properties" file and passed at the time of analysis (correct me if I am wrong). But the problem is since I am using MSBuild SonarQube Runner, sonar-project.properties file is not used anymore and the project properties are passed at the analysis time. If that is the case how should I pass them in?
I searched a lot but could not find a proper solution in this manner and I'd be very glad if someone could help.
Thanks in advance.
Additional properties are passed to the MSBuild SonarQube Runner during its begin phase using the following syntax: /d:key=value.
So, you can pass all of them:
MSBuild.SonarQube.Runner begin /k:... /n:... /v:... /d:sonar.scm.enabled=true /d:sonar.scm.provider=tfvc /d:sonar.tfvc.username=... /d:sonar.tfvc.password.secured=....
Auto-detection of the SCM will work if there is a $tf at the "project base dir" level. That directory is computed as the first ancestor path common to all your *.csproj files. You can see its value following the file generated during the end phase: .sonarqube\out\sonar-project.properties. Look for the sonar.projectBaseDir property value near the end of the file. See https://jira.sonarsource.com/browse/SONARMSBRU-8 for details.
Related
I'm trying to use SonarScanner with SonarCFamily plugin on my C codebase on ubuntu. I see that the scanner is able to only detect "code smells - duplicate blocks of code" in my codebase and no other forms of bugs/vulnerabilities. I intentionally added a memory leak in the code and SonarQube couldn't detect it while open source SA tool Cppcheck was able to. Am I missing some setting in the sonar-project.properties file ? My sonar.properties file is as follows. Are there any settings needed in the server/SonarCFamily plugin for the tool to detect other forms of SA errors ?
# must be unique in a given SonarQube instance
sonar.projectKey=c-sa-test
# this is the name and version displayed in the SonarQube UI. Was mandatory prior to SonarQube 6.1.
sonar.projectName=c-sa-test
sonar.projectVersion=1.0
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
# This property is optional if sonar.modules is set.
sonar.sources=src
# Encoding of the source code. Default is default system encoding
sonar.sourceEncoding=UTF-8
sonar.host.url=http://localhost:9000
sonar.cfamily.build-wrapper-output=bw_output
sonar.c.file.suffixes=.c,.h
sonar.cpp.file.suffixes=.cc,.cpp,.cxx,.c++,.hh,.hpp,.hxx,.h++,.ipp
Found the root cause - Was missing providing some elements of the project build process as input to the build wrapper. Once those were added, SonarQ provided a detailed report.
I had the exact same problem where SonarCFamily was only reporting code duplications. It was due to an incorrect build process as input to the build wrapper. In my case, I was using SonarScanner.MSBuild and on my build-wrapper line, I didn't have the Configuration and Platform specified, so my projects were not getting built or scanned. The final working lines were:
SonarScanner.MSBuild.exe begin /k:"your key" /d:sonar.cfamily.build-wrapper-output=”bw_output”
build-wrapper-win-x86-64.exe --out-dir bw_output MSBuild.exe your_solution.sln /p:Configuration=Release /p:Platform=x64
SonarScanner.MSBuild.exe end
I try to analyze one module of a multi module project in Jenkins with SonarQube Scanner plug-in (version 2.5). Unfortunately, Jenkins picks the wrong module as working directory.
In this particular case, I could change the order of the modules, but in general (more than one analyzed module) it is not working. So I want to fix the problem with the property sonar.projectBaseDir, see Advanced SonarQube Scanner Usages:
Alternate Analysis Directory
If the files to be analyzed are not in the directory where the analysis starts from, use the sonar.projectBaseDir property to move analysis to a different directory. E.G. analysis begins from jenkins/jobs/myjob/workspace but the files to be analyzed are in ftpdrop/cobol/project1.
sonar-project.properties
sonar.projectBaseDir=/home/ftpdrop/cobol/project1
sonar.sources=src
sonar.cobol.copy.directories=/copy
I tried following ways to set the sonar.projectBaseDir property to right module (module2 instead of module1):
sonar.projectBaseDir in sonar-project.properties file
But it doesn't work. The property in sonar-project.properties file is ignored. The log shows that the property is overriden with JVM option:
/Users/test/jenkinsslave/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarQube_Scanner_2.8/bin/sonar-scanner -X -e -Dsonar.host.url=http://sonarqube:9090 -Dproject.settings=/Users/test/jenkinsslave/workspace/Test/module2/sonar-project.properties -Dsonar.projectBaseDir=/Users/test/jenkinsslave/workspace/Test/module1
I think that is a bug in SonarQube Scanner plug-in, because project.settings is incompatible with sonar.projectBaseDir, see Advanced SonarQube Scanner Usages:
The property project.settings can be used to specify the path to the project configuration file (this option is incompatible with the project.home and sonar.projectBaseDir properties).
sonar.projectBaseDir as JVM Options
But it doesn't work. The property is ignored. The log shows that the property is overriden:
/Users/test/jenkinsslave/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarQube_Scanner_2.8/bin/sonar-scanner -X -e -Dsonar.host.url=http://sonarqube:9090 -Dsonar.projectBaseDir=/Users/test/jenkinsslave/workspace/Test/module1
sonar.projectBaseDir as Additional arguments
But it doesn't work. The log shows that the property is configured twice:
/Users/test/jenkinsslave/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarQube_Scanner_2.8/bin/sonar-scanner -Dsonar.projectBaseDir=/Users/test/jenkinsslave/workspace/Test/module2 -X -e -Dsonar.host.url=http://sonarqube:9090 -Dsonar.projectBaseDir=/Users/test/jenkinsslave/workspace/Test/module1
I think that is a bug in SonarQube Scanner plug-in, because it should not add sonar.projectBaseDir option if there is already such option.
I found a solution, I have to add the property sonar.projectBaseDir as Analysis properties.
Configuration:
Log:
/Users/test/jenkinsslave/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarQube_Scanner_2.8/bin/sonar-scanner -X -e -Dsonar.host.url=http://sonarqube:9090 -Dsonar.projectBaseDir=./../module2
Current my scanner is running through and only scanning the parent and skipping the rest of my nested files. If I run sonarlint (using the cli and specifying some test and source files) , it tries to analyze 37k files instead of the few I need. I have been able to skip ~3k files by adding the <sonar.skip>true</sonar.skip> property to a pom file. However, I still can't configure the project to run across certain sub-folders and print out some kind of code coverage test. (Is JaCoCo needed for the latest version(6.3,0)? Or can code-coverage be handled through some configuration?).
If Sonar seems to be analyzing too many files, it is probably because you had not set the sonar.sources=src/main/java in your sonar-project.properties file, so it defaults to the basedir and includes everything.
SonarQube can't do code-coverage itself, it just reports on coverage-reports from a tool like JaCoCo. It is funny they don't clarify these things in https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner --but with enough digging, you can find good info on that site.
I’m integrating SonarQube in our build system – I installed sonar-runner-2.4 on our build agents and added the sonar-runner.properties for each solution (to the solution’s folder on TFS).
When running the build I’m executing the sonar-runner after the solution has been compiled on the build agent.
Everything seem to work except for the unit test:
On the build’s log I see that almost 200 tests ran and were completed successfully and in the sonar-runner log I see the following:
14:23:29.808 INFO - 583/583 source files analyzed
14:23:30.809 INFO - Sensor org.sonar.plugins.csharp.squid.CSharpSquidSensor#1a50b87 done: 14937 ms
14:23:30.809 INFO - Sensor org.sonar.plugins.csharp.core.CSharpUnitTestResultsProvider$CSharpUnitTestResultsImportSensor#97edbc...
14:23:30.821 INFO - Sensor org.sonar.plugins.csharp.core.CSharpUnitTestResultsProvider$CSharpUnitTestResultsImportSensor#97edbc done: 12 ms
Which seems ok I guess, but when logging into the sonar server it shows that 0 tests ran.
On the sonar-runner.properties file I set the following value to
sonar.cs.vstest.reportsPaths:
sonar.cs.vstest.reportsPaths=TestResults/*.trx
when in this case there are 3 vstest trx files located in the following local path on the build agent: `
D:\sTFS\22965\Sources\TestResults
` (see TestResults.jpg attached).
Attached is the sonar-runner.properties file.
I also attached a screen capture from the sonarqube server (see SonarServer.jpg attached).
Can you please advise what might be the problem?
You should be seeing some messages like:
INFO - Parsing the Visual Studio Test Results file ...
for each unit test result file that is being parsed, see VisualStudioTestResultsFileParser.java#L34
Can you try to pass an absolute path pattern to sonar.cs.vstest.reportsPaths? My guess is that the issue comes from the relative path.
By the way, the use of the sonar-runner to analyze .NET projects is being deprecated. You'll want to have a look at the MSBuild SonarQube Runner that offers very good integration with Team Foundation Server. See the new C# plugin documentation on SonarSource's Wiki: http://docs.sonarqube.org/display/PLUG/C%23+Plugin
EDIT
I just noticed the package name from your logs org.sonar.plugins.csharp.core.CSharpUnitTestResultsProvider. The .core. was present only in outdated versions of the C# plugin (in the 3.x series), and these versions might not support wildcards in report paths. Please upgrade to the latest version.
Maybe, this question is silly but I'm very new. I try to search without luck.
I got two errors when building maven project with sonar:
No information about coverage per test.
Although I had test code and these testing classes cover the code.
The global property 'sonar.doxygen.deploymentPath' is not set. Set it in SONAR and run another analysis.
I dont know it should be set where in sonar server. I set in web.xml or sonar-server.properties but it does not work.
Thanks.
About the first warning message this is not an error but a warning : since Sonar 3.5 this is possible to get the code coverage relating to each unit test. Here the message just says that this feature is not activated which is expected by default. Nevertheless I do agree that this warning message can be misleading.
About the second error message, I don't know the doxygen plugin but the message seems to be pretty clear : the sonar.doxygen.deploymentPath property has not be defined. See the plugin documentation : http://docs.codehaus.org/display/SONAR/Doxygen+Plugin.
Two things:
There is no war folder anymore since the sonarqube has given up tomcat support
The doxygen plugin is not implemented to upload the files in to the sonarqube server &/ installation, which means it only can be done by referencing the path inside your installation, e.g.:
run "mvn install sonar:sonar" in your project "/root/test.example.sonar.com"
in sonarqube set the cfg-key "sonar.doxygen.deploymentPath" the value: "/root/sonarqube-4.1.1/web/" and the cfg-key "sonar.doxygen.deploymentUrl" the value: "http://:9000"
have fun with your doxygen
Remember that the plugin will only be run through your mvn cmd, refreshing the page only will not do the job, you will have to analyse again after each cfg set :/
Check the file system and folder permission