• General
• Integration into Maven Pipeline
  • Preconditions at SQ server
  • Jenkins Integration
• Jenkins Plugin

General

To use SonarQube to perform source code quality and security tests with Jenkins, two components are required:

• SonarQube server (instance) to perform analysis, evaluation, data storage, generate reports, define quality gates etc. This server is currently not provided by Devops-as-a-Service.
• Sonar Scanner in Jenkins to perform the actual scanning of source code. The scanner transfers the intermediate results to the SQ server for analysis and evaluation. 

In the following, "SQ" is used as an abbreviation for "SonarQube". 

Integration into Maven Pipeline

Preconditions at SQ server

• A SQ server running anywhere and accessible from the Jenkins build agent (public URL preferred)
• Configuration of "Server base URL" in Administration / General according to the URL of the SQ server. This is required to include correct links to the Jenkins pages.
• A project and token must be created in SQ server→ Record the produced Maven command to be included into the Jenkinsfile and the Credential store (see remark below).

Jenkins Integration

The integration of a SQ scan into a Maven build pipeline is quite easy and doesn't require the SQ plugin in Jenkins. SQ scans can be triggered from the Jenkinsfile just using maven commands. 

See https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-maven/ for official documentation.

Just execute the Maven command from the project setup in SQ  in the Jenkinsfile, like this:

If the source code has not been compiled yet, use instead

Additional parameters can be defined, see https://docs.sonarqube.org/latest/analysis/analysis-parameters/ for a complete list. As a result, the scan is performed on the Jenkins agent and the results transferred to the SQ server. The artifactId as configured in the pom.xml of your build will be used to name the new project on your SQ server. No reports will be stored in Jenkins workspace.

DevOps-as-a-Service integrates the SQ plugin in the provided Jenkins instance but the parameters of the SQ server are not globally configured by default. Only a symbolic server name "sonarserver" is configured, which must be used in the pipeline code, see example below.  Using the SQ plugin, a scan can be triggered using the following code example. It's the same Maven command as above, only wrapped in withSonarQubeEnv() to refer to the globally configured "sonarserver".

As an alternative to specifying URL and LOGIN on each SQ scanner run, it can be globally configured in Jenkins Master by creating a Service Request at https://prd.sdc.t-systems.net/jira/servicedesk/customer/portal/3.

The integration of other build types than Maven is described here:  https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-jenkins/

Jenkins Plugin

DevOps-as-a-Service includes the SQ plugin https://plugins.jenkins.io/sonar/ in its Jenkins. Documentation is available here https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-jenkins/

The SQ plugin provides these added values:

• Injection of globally defined parameters (URL, project name, token, options...) into the build
• Integration of a SQ-Link at the repo/branch Jenkins page
  
• Integration of a SQ-Link next to the build in the build list. The link forwards to the corresponding project/event in SQ server.
  
• Jenkins can wait for analysis at SQ server and display the result of a quality gate in the pipeline view. For this the waitForQualityGate step as documented at https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-jenkins/ needs to added to the pipeline. Unfortunately the API call from the Jenkins Plug-in to the SQ server instance will only work if the URL and access token has been globally configured in Jenkins as define above. The sonar result will be added to the repo/branch page below the Stage View.
  
  No further results or details will be available in the Jenkins UI. The SQ UI must be used to check results and define the quality gates.