I want to use sonar to monitor the junit test code coverage for a grails project. firstly I use grails code coverage plugin to generate the coverage.xml and configure sonar.groovy.cobertura.reportPath property, but there is no data in junit part. So I change the sonar.sources in the pom.xml from grails-app to grails-app/controllers,grails-app/services,grails-app/domain. then the junit code coverage appears but the console shows resource is not index.and the issues part in sonar dashboard becomes 0. How can i solve that? thank you very much.
sonarqube 4.5.1
Groovy sonar plugin 1.0.1
maven 3.2.5
the pom configuration is below:
<sonar.language>grvy</sonar.language>
<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
<sonar.surefire.reportsPath>test/reports</sonar.surefire.reportsPath>
<sonar.groovy.cobertura.reportPath>test/reports/cobertura/coverage.xml</sonar.groovy.cobertura.reportPath>
<!--sonar.groovy.codenarc.reportPath>test/CodeNarcReport.xml</sonar.groovy.codenarc.reportPath-->
<sonar.sources>src/groovy,src/java,grails-app/controllers,grails-app/services,grails-app/domain</sonar.sources>
BR,
victor
It seems that your problem is related to the following issue: http://jira.codehaus.org/browse/SONARGROOV-8
Note that the ticket has been resolved and the fix will be part of version 1.1 of the plugin (requires SQ 4.5.2).
As the plugin has not yet been released, you may want to test the snapshot. Please refer to this thread: http://sonarqube.15.x6.nabble.com/VOTE-Groovy-Plugin-version-1-1-td5033128.html
Related
Since I updated my sonarqube server to 6.1 I'm getting this error in my gradle project.
I'm using sonar plugin latest version (2.2)
classpath("org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.2")
anyone knows how to solve it?
Thanks!
I resolved this problem by delete the cobertura jar file in the plugins folder. It seems sonarqube 6.1 does not support cobertura any more. because after i delete the file i can't find cobertura in the sonar plugin management page.
There was a known issue from 2014 that UnitTests written in Groovy cannot have their PASS/FAIL metrics uploaded into SonarQube.
http://sonarqube-archive.15.x6.nabble.com/Resource-not-found-for-Groovy-unit-tests-td5024669.html
Does anyone know if this issue is fixed? I am still have the issue with Sonar 6.1 using Spock unit tests and Gradle build system.
Any clue on the correct gradle sonar settings to make this happen?
The solution for us was to install the Groovy plugin in Sonarqube 6.1.
Once the plugin was installed, we could see the tests, with this command line:
./gradlew sonarqube -Dsonar.tests=src/test/groovy -Dsonar.junit.reportsPath=build/test-results/test/
We are using Spock as well (with Gradle, as you can see)
I have scoured the forums and cannot seem to quite understand the config for the fortify plug-in with Sonar.
I understand it simply builds a widget based on data from a previously generated .fpr file.
My setup:
Maven 3 project
Jenkins 1.606
SonarQube 5.0.1
Sonar-Fortify plug-in 2.0
Prerequisites:
.fpr file is in Jenkins workspace
Sonar is added to pom.xml
sonar-fortify-plug-in v2.0 added to pom.xml - (wasn’t sure this was needed or not)
Sonar server configured in Jenkins
sonar fortify plug-in v2.0 added to Sonar – (only see a dropdown to ‘enableReportLink’ under ‘Configure widgets’
should there be more config somewhere?
Questions:
Where should this property be set? Jenkins Sonar config, Sonar, pom file?
sonar-runner -Dsonar.fortify.reportPath=/path/to/project.fpr
Is that path to the .fpr file where it is within the Jenkins workspace?
The setup instructions on Github seem short and I feel I am missing something specific in my understanding.
Any help or direction to additional documentation is great appreciated.
First of all as documented version 2.0 can not be used anymore. Version 2.1 is going to be released soon. Vote for release will be started this week. Meanwhile you can:
download 2.1-SNAPSHOT version and copy it in extensions/plugins of your SonarQube server installation
restart server. The Fortify rules should be available in the page "Rules".
execute Fortify command "sourceanalyzer", independently from SonarQube. It generates a report file suffixed by .fpr.
execute a standard SonarQube analysis of your project by adding the property sonar.fortify.reportPath, for example:
mvn sonar:sonar -Dsonar.fortify.reportPath=/path/to/project.fpr
sonar-runner -Dsonar.fortify.reportPath=/path/to/project.fpr
If everything works, then you can automate these steps in Jenkins.
I have recently upgraded Sonar from Version 3.4.1 to Sonarqube 4.3.2. I am using Cobertura version 1.6.2 and Java plugin 2.3 in Sonar.The Unit Tests Success% is same that is 100% in both the cases but there is difference in the Code Coverage% being displayed (Earlier it was 22.7% and now in Sonarqube 4.3.2,it is 15.9%).The difference is significant.Also there is difference in the Lines of Code after upgradation (Earlier it was 1,906 and after upgradation it is 2,704).Anyone having idea that what can be the reason for this difference.
Any help is appreciated.Thanks in advance.
Maybe you have you have analysis/coverage exclusions activated on your 3.4.1 instance but not on your 4.3.2 instance. This would explain the coverage difference / lines difference.
Check in globlal settings and project settings :
Global Source File exclusions
Source File exclusions
Jacoco excludes
We had the exclusions mentioned in pom.xml but in 4.3.2 version we came to know it needs to be specified on Sonar UI under •Global Source File exclusions
or Source File exclusions.but this didn't work either for LoC.
Is there a way to get sonar to use the checkstyle configuration from my pom file? I have the maven checkstyle plugin setup, and I have the maven sonar plugin (version 2.7) setup, but sonar seems to use its default checkstyle configuration. I know I can create a new quality profile and upload the checkstyle file, but I would think that the maven plugin should use the one from the pom. Any help here is appreciated.
thanks,
Jeff
It used to be possible from Sonar 1.11 to Sonar 2.2 by using a parameter sonar.reuseExistingRulesConfiguration. It was removed from Sonar 2.3.
See SONAR-583
See SONAR-1706