Some of the most important decisions a release or build manager has to make are whether to promote builds through the CI pipeline. To make these decisions smart and qualified, quality metrics are needed to point out problems in the builds. But sometimes, the problems are at the source, and to detect those problems, you need a tool like SonarQube.
SonarQube analyzes source code to detect tricky issues — things like bugs, code smells, and security vulnerabilities — that impact code quality. It can also be configured to measure those results against a set of Quality Gate Metrics whose thresholds you define, to help identify code that may cause problems before it is built or deployed.
This post describes how Artifactory and SonarQube can be configured to work together in a CI/CD pipeline, to catch builds constructed from poor quality code before they make it through the pipeline to production.
Integration by Metadata
The integration between SonarQube and Artifactory is implemented by attaching metadata from SonarQube, such as Quality Gate failures, to builds hosted in Artifactory. This metadata can be leveraged further down the pipeline to help decide whether builds (corresponding binaries) should be promoted and/or used in production or not.
A SonarQube analysis can be added to a stage of your CI pipeline. Typically, this will be done in the configuration of your CI server such as Jenkins, TravisCI or CircleCI.
Take a look at this Git repository that includes a shell script, called artifactory-sonar.sh, that with minor modifications to accommodate your specific environment, can be used by your CI server to invoke the SonarQube analysis and deliver its quality metrics information to Artifactory.
For example, if you are using Jenkins, you can add the artifactory-sonar.sh script to the post-build phase definition in your JenkinsFile:
The shell script allows Artifactory to capture the compute engine identifier for the SonarQube analysis (CeTaskId) in Artifactory’s buildinfo. This identifier provides access to the quality gate details the SonarQube analysis produced in that build. Release and build managers can use that information to decide (or automate the CI pipeline to decide) whether or not to promote a build to production.
Act Now or Later – You Choose
The Artifactory/SonarQube integration can be used in two operating modes: WAIT (blocking) mode (the default) or NOWAIT (non-blocking) mode.
In WAIT mode, the integration waits for the SonarQube analysis to complete, and then decides whether to fail a build or not.
This mode is recommended for projects with small build times or if build time does not matter.
As shown before, this is how you would add this check to the Post Build phase of a JenkinsFile.
If you want to always override the SonarQube quality metrics so that it does not fail the build, invoke the script with the argument false.
In NOWAIT mode, the script will not wait for the SonarQube analysis to complete, but will only store the compute engine identifier for the analysis (CeTaskId) as part of Artifactory’s buildinfo. This information can be used later in the pipeline to query SonarQube for the quality gate status for that build.
This mode is recommended for large projects where it is unacceptable to make the build wait for the SonarQube analysis.
To invoke in no wait mode, execute:
You can download and use this script as a reference, however, you may need to modify it for your needs as pipelines and conventions vary from company to company.
Further details about the implementation can be found in the README document of the project:
Are you ready for some SonarQube quality gate metrics in Artifactory?