...
The SonarQube system analyzes source code for problems and reports the results, including test code-coverage statistics, to https://www.sonarcloud.io. The analyses are usually run weekly by a Jenkins job. This section summarizes the project configuration that is required. Analyzing and reporting static source-code features requires almost no configuration, basically just naming the directory with source code. Reporting Each project's build and test steps must generate code-coverage statistics, which requires automated unit tests that can be run by Jenkins.
This section focuses on configuration to generate coverage data suitable for consumption by the Sonar scanner. See the section later in this document on Jenkins job configuration for details about that the project's build and test steps generate those statistics, which requires automated unit tests that can be run by Jenkins. This section focuses on test configuration to generate coverage data suitable for consumption by the Sonar scanner. See the section later in this document on Jenkins job configuration for details about that.
Configure CXX Project for Code Coverage
CXX projects require use of a dedicated tool, the Sonar build wrapper, as documented here: https://docs.sonarqube.org/latest/analysis/languages/cfamily/ The build wrapper is used to invoke cmake. The wrapper then gathers data without further configuration. This tool is automatically installed and invoked in CMake-style Jenkins jobs, implemented by the cmake-sonarqube.sh script from LF's global-jjb. Actually no configuration changes are required in the project's CMakeLists.txt or other files, just use of the appropriate Jenkins job template.
Execution of the build via make should create the output file build-wrapper-dump.json, which can be consumed by the Sonar scanner.
Configure Golang Project for Code Coverage
...
go-acc $(go list ./... | grep -vE '(/tests|/enums)' ) |
This Execution of the build via this command should create the output file coverage.txt, which can be consumed by the Sonar scanner. However modules are not supported yet by the Sonar Scanner. The problem and some workarounds are described here: https://jira.sonarsource.com/browse/SONARSLANG-450
...
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.4</version>
<executions>
<execution>
<id>default-prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>default-report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin> |
This Execution of the build via maven should create the output file target/jacoco.exec, which can be consumed by the Sonar scanner.
...
commands =
pytest --cov dir-name --cov-report xml --cov-report term-missing --cov-report html --cov-fail-under=70
coverage xml -i |
This Execution of the build via tox (really just tests) should create the output file coverage.xml, which can be consumed by the Sonar scanner.
...
