Get test builds from GitHub Actions (click on a recent run and get the artifacts from the bottom of the page).
WARNING: This project is currently unmaintained. If you want to take over maintainership, please contact me (see mail address in recent commits) and I'll arrrange a repository move and inform SonarSource about the new maintainer.
This plugin enables analysis of Groovy within SonarQube.
It leverages CodeNarc to raise issues against coding rules and GMetrics for cyclomatic complexity.
For code coverage, the SonarQube JaCoCo plugin should be used. Additionally, this plugin still supports importing binary JaCoCo reports (deprecated, will be removed in the future) and Cobertura.
| Plugin | 1.4/1.5 | 1.6 | 1.7 | 1.8 |
|---|---|---|---|---|
| CodeNarc | 0.25.2 | 1.4 | 1.4 | 1.6.1 |
| GMetrics | 0.7 | 1.0 | 1.0 | 1.1 |
| SonarQube | 5.6-6.7 | 6.7-7.9 | 7.8-8.9 | 8.0-9.0 |
- Install SonarQube Server
- Install SonarQube Scanner and be sure you can call
sonar-scannerfrom the directory where you have your source code - Install the Groovy Plugin.
- Create a sonar-project.properties file at the root of your project
- Run
sonar-scannercommand from the project root dir - Follow the link provided at the end of the analysis to browse your project's quality in SonarQube UI
CodeNarc: It is possible to reuse a previously generated report from CodeNarc
by setting the sonar.groovy.codenarc.reportPaths property.
Groovy File Suffixes: It is possible to define multiple groovy file suffixes
to be recognized by setting the sonar.groovy.file.suffixes property. Note
that by default, only files having .groovy as extension will be analyzed.
Unit Tests Execution Reports: Import unit tests execution reports (JUnit XML
format) by setting the sonar.junit.reportPaths property. Default location is
target/surefire-reports.
JaCoCo and Binaries: The groovy plugin requires access to source binaries
when analyzing JaCoCo reports. Consequently, property sonar.groovy.binaries
has to be configured for the analysis (comma-separated paths to binary
folders). For Maven and gradle projects, the property is automatically set.
For coverage, it is recommended to use the generic SonarQube JaCoCo plugin instead of relying on this plugin to import coverage into SonarQube. Nevertheless, we support importing coverage from Cobertura (but this code path isn't used by the author of the plugin).
To display code coverage data:
- Prior to the SonarQube analysis, execute your unit tests and generate the Cobertura XML report.
- Import this report while running the SonarQube analysis by setting the
sonar.groovy.cobertura.reportPathproperty to the path to the Cobertura XML report. The path may be absolute or relative to the project base directory.
Contributions via GitHub issues and pull requests are very welcome. This project tries to adhere to the Google Java Style, but we don't want a global reformat to keep the Git history readable. To help with this, we use the "ratchet" feature of spotless. If you get an error from spotless during build or CI, you can fix them with:
mvn spotless:apply
In the directory codenarc-converter there is a little helper tool to convert
CodeNarc rules to SonarQube rules. To do its job it needs a source copy of
CodeNarc - this is currently achieved by including the used CodeNarc version as
a git subbmodule. If you need to update CodeNarc, you need to update that
submodule too:
git submodule init
cd codenarc-converter/CodeNarc
git checkout vX.Y.Z
cd ..
git add CodeNarc
You should then run the codenarc-converter (Running mvn verify should be
enough if the project is set up correctly) and merge descriptions from
codenarc-converter/target/results/rules.xml into
sonar-groovy-plugin/src/main/resources/org/sonar/plugins/groovy/rules.xml.
The converter does a pretty crude job converting CodeNarc's APT documentation
into SonarQube rule descriptions.