This series of articles on installing SonarQube will end with this post. Let’s remember what were the objectives:

• Establish an environment of code analysis to measure the quality of applications.
• Without requiring technical knowledge about Java, databases, network, or open source tools.

You are a pro in the Mainframe Cobol or SAP worlds, or a quality consultant, you act as as stakeholder or an interface between users and project teams, you are a project manager in charge of managing outsourcers for your IT department: this series showed you how to install SonarQube on your PC (a simple laptop in my case) in order to easily and regularly analyze any delivery of code or a new version of an application.

And this last episode of this series will be about how to manage SonarQube analysis with Jenkins. For this, I will reuse the same Java code I previously analyzed with the SonarQube Runner.

Creating a SonarQube analysis with Jenkins

First, we will create a project from the Jenkins menu located in the upper left corner of the main page.

Select the menu ‘New Project’ (Nueva Tarea’ in my spanish interface): Jenkins displays the creation page of a project.

It is possible to create different types of projects according to the equipment used (such as Maven). With SonarQube, we will choose the first option ‘Build a free-style software project’ (‘Crear a proyecto de estilo libre’ in the screen below) and enter a project name: ‘Extranet’ in our example. The ‘OK’ button at the end of the page becomes active.

Note that you will get an error message if you try to use a project name that already exists.

Click the ‘OK’ button to access the configuration page of the project.

I will not detail the many options available on this page, as I only use the one for log management, in order to automatically remove those beyond a certain date, or when they become too numerous.

So we simply select the ‘Add New Task’ button that opens the following list of menus in which we choose ‘Invoke Standalone Sonar Analysis’.

This opens the configuration page for this project:

I just have to input into this page the localization of the ‘properties’ file with all the parameters used for our first analysis with the SonarQube Runner: they were defined in a ‘sonar-project.properties’ file located in a ‘..\Projects’ folder (under the ‘home’ directory of the SonarQube Runner).

And in this post, I told you it was important to manage your environment by clearly defining where are located, for each application, the source code and everything which contributes to the configuration of the analysis. I use, for each project, a directory ‘Source’ with the corresponding code, and a folder ‘Implementation\Conf‘ in which I’ll keep the specific (properties) file with the same name than the analysis.

This method has many advantages, including:

• You can easily find the parameters of any analysis, even a long time after you did it.
• You can easily duplicate the settings of an analysis that works perfectly with a copy of the same properties file for a new project. You still have to modify the values ​​for these properties, but I know I would not have forgotten anything in my settings, so that no error will come from it.
• If you work together on a shared server, following the same configuration (and similar practices) will allow you to go on holiday without any worry: all other members of your team will know exactly how to take in charge your projects without having be part of them. This shall not preclude a bit of documentation (to keep in an ‘Implementation\Docs\’ directory) but it will be very brief: a single sheet description of the application and your analysis.

So, I use exactly exactly the same parameters than the ones used for our first analysis with the SonarQube Runner.

Another advantage is that Jenkins, well the SonarQube plugin for Jenkins, allows me to override any value in this file from the ‘Invoke Standalone Sonar Analysis’ configuration page and, as you can see in the previous figure, specify a new version number for this analysis or application:

sonar.projectVersion=1.1

Don’t forget to save you settings before launching a new analysis.

Execution and log

A progress bar shows where you are in the analysis.

Then, a contextual menu allows you to see the log for this task, while it’s working or at the end of it.

If you click on the image above, you can see the various parameters that we actually defined in our Jenkins configuration.

In the same log page, you have a menu that allows you to view the log in text mode in order to save it as a file and/or send it by email, for example.

And finally, here is the result in SonarQube.

 

We have seen in this article the main advantages of using Jenkins with SonarQube:

• Organize our analysis environment as desired, with a specific configuration file for each project, that we can duplicate at will.
• Override a parameter – as the version number – for each analysis.
• Have a much more user friendly log to consult.

Voilá, This is all it is necessary to know to implement your own analysis environment and easily measure the quality of applications and different technologies, without requiring any special technical knowledge.

About, different technos and languages, you may be interested by two other series on my blog, about the analysis of  Cobol ou SAP applications with SonarQube.

Up to you now. And do not hesitate to let a comment here if your analysis are successful.

 

This post is also available in Leer este articulo en castellano and Lire cet article en français.