I am using sonarqube 5.6.1 with gradle plugin 2.1.
I can't exclude test folders from report issues.
property 'sonar.exclusions', 'src/test/, build/'
Test folder is not excluded while build folder is.
I can exclude the whole test folder, however, all my test source and results are gone. Unit test result is important. I need them.
property 'sonar.test.exclusions', 'src/test/**'
How can I archive both exclude test source from reporting issue and showing unit test result?
This is a bug. Sonarqube must provide a way to stop reporting issue in test code. My directive is to fail the build if the quality gate fails. It is not correct to fail my build because test code has quality issue.
Related
I have a TeamCity project that runs Jmeter via Maven in a build called "PerfRunner" under the project "Audit-Service-Performance". When it runs Jmeter produces a target dir with a report html file, index.html.
I want TeamCity to create a report tab with the latest report from the latest successful.
Folder structure relative to artifact:
target
-jmeter
--bin
--lib
--logs
--reports
---jmeter-deng-audit-standalone_time_stamp
----index.html
--results
--testFiles
The problem is that the time_stamp in meter-deng-audit-standalone_time_stamp is auto generated and therefore changes with each build.
When I try to create a report tab I do a project or build report tab I tried:
target/jmeter/**/index.html. But it doesn't generate the report tab.
The only way I can get it to work is if I address a static file for a particular build which of course wont be the latest once a new build is run.
The MVN command runs clean. How can I make it dynamic?
You need to publish this index.html page as the build artifact. If you want to share the page with the others you can go for one of the following patterns of accessing build artifacts:
/repository/download/BUILD_TYPE_EXT_ID/.lastFinished/index.html
/repository/download/BUILD_TYPE_EXT_ID/.lastSuccessful/index.html
/repository/download/BUILD_TYPE_EXT_ID/.lastPinned/index.html
/repository/download/BUILD_TYPE_EXT_ID/BUILD_ID:id/index.html
/repository/download/BUILD_TYPE_EXT_ID/BUILD_NUMBER/index.html
You can also consider using JMeter Teamcity Plugin - it adds Performance Statistics tab where you can observe performance trend for last builds
Check out How to Run JMeter Tests with TeamCity for Continuous Integration article for more information on how to configure JMeter to work with Teamcity
I'm not able to see the Integration Tests in new sonarqube 6.7 version, here is what I'm doing,
Run Sonarqube task with Gradle to generate the report along with code coverage.
Here, Sonarqube is by default invoking test task and using the test.exec file from build/jacoco generated by Jacoco plugin.
However, I've a task depends on the test task to place an integrationTest.exec report in the build/jacoco as the integrations tests are run outside build(for some reason)
Though I place the integrationTest.exec file explicitly while Sonarqube execution it is still not considering the report and due to which I do not see any change in the coverage computed also I do not see Integration Tests section under coverage like I see Unit Tests.
Firstly, I would like to understand that whether is it feasible to export the integration tests result like I did above or not?
Second, is the latest Sonarqube having the capability to show integration tests report in the coverage section?
Your comments would help me.
Thanks in advance!
I have several java projects with no unit test cases. When I try to analyse these projects using SonarQube I am unable to get unit test code coverage because it doesn't have any test cases. As per my research I saw that I can force it to show it as zero if there are no unit test cases. The official Jacoco Java documentation mentions sonar.jacoco.reportMissing.force.zero=true.
My SonarQube analysis will be done using maven builds and SonarQube 5.6.6 and sonar-java 4.11.0.10660.
How can I set this parameter in maven so that it can show as zero unit test cases in my coverage?
From version 6.2 SonarQube does this automatically where the behavior is supported by the analyzers. Before that version, availability of the feature is spotty and not entirely reliable. For best results you should upgrade SonarQube.
That said, you can set that property on the analysis command line like so:
mvn sonar:sonar -Dsonar.jacoco.reportMissing.force.zero=true
Or by setting a property in your pom, as shown in the docs
Update 16 Dec 2019
Most language analyzers now calculate Executable Lines, so files omitted from the coverage report are included in calculations anyway. But that only kicks in if you provide coverage reports. No coverage reports -> no coverage metrics at all.
In sonarQube, how to reference the unit test report residing in the server pertaining to Continuous Integration tool? Please note that the sonarQube and CI tools are in different servers. This is needed to show unit test coverage in sonarQube.
Usually, the build of a project does operations like:
Checkout source code
Build source code
Run unit test and generate coverage reports
Run a SonarQube Scanner to trigger the analysis
All this happens within the CI server. This means that you just need to configure your SonarQube analysis to point to the local coverage report files that have been generate just before.
For example, take a look at the following project:
Sample project that reads coverage reports
, and especially to its sonar-project.properties file, in which you will see that coverage report files are referenced using relative paths.
I am analysing a Java project that has been unit tested and Cobertura coverage.xml reported. I am using SonarQube 4.1.1 and latest Sonar Runner. I have successfully imported Cobertura coverage results to Sonar 3.2 and Ant analyzer, but with this new version I am running into problems. In the new Sonar analysis execution (through Jenkins) I see no reference in logs that it would have started any Cobertura engine or anything. My settings in Runner Jenkins project:
sonar.dynamicAnalysis=reuseReports
sonar.java.coveragePlugin=cobertura
sonar.cobertura.reportPath=[mypath]/coverage.xml
sonar.junit.reportsPath=[mypath]/
No mentioning of Cobertura in the analysis output (except my own property values) and SonarQube page shows "-" in coverage report. Unit test results are shown fine.
I have also added all source, bin, and test directories. Any ideas? Thanks.
Update
I wonder if the reason why Cobertura coverage is not reported on SonarQube page, is because in Jenkins my SonarQube project clones (Clone plugin) the workspace from a previous Project build? If the coverage.xml file contains static paths, then maybe it goes wrong somehow.
Ok the solution was quite obvious. SonarCube 4.1.1 does not come with Cobertura preinstalled, so I installed it and now it works :) Maybe it was preinstalled in 3.2 version, I can't remember.
For any "reuse reports" feature in SonarQube (may it be for code coverage, test execution or any other third-party tool that generates a intermediate report), the report must be generated based on the same source files (in terms of file system location) than the ones that will be used for the SonarQube analysis. Otherwise the SonarQube plugins won't be able to match paths from the reports with paths of the analyzed sources.
So you guessed it right: cloning the workspace and running the SonarQube analysis on this clone is the reason why the coverage can't be computed.
The root cause of this problem is that SonarQube does not support Cobertura format and you need OpenCover, or dotCover format. Using reportgenerator is one of the solutions but it's unnecessary complicated: you can make "dotnet test" command to return the report in Opencover format by passing special parameter and then pick up the Opencover report.
Use
dotnet test --collect:"XPlat Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=cobertura,opencover
to get two reports: one in OpenCover format for SonarQube and default Cobertura for Azure DevOps.
Now you can specify the path to OpenCover report in SonarQubePrepare task.
There is also detailed article on this here