We saw in the previous post how to install the Sonar plugin for Jenkins. It is now time to make our first analysis from Jenkins. It will focus on the Cobol source code already used in our first analysis with Sonar and the Java Runner.

For this, we will create a project from the main page of Jenkins.

In the creation page, we enter a project name and select the first option:

This opens the configuration page of this project, in which we say that we want a Sonar analysis:

Now, we just have to specify our configuration file, the same as the one used during our first analysis wiht Sonar : C:\Soft\Sonar\sonar-runner-1.1\Projects\sonar-project.properties:

But first, we will enter a new version into this configuration file: sonar.projectVersion=1.1.

Don’t forget to save the parameters of this project.

Before to start it.

And while it is running…

 

We can have a look to the log:

Then look at the result of the analysis into Sonar, with the version number indicated into our configuration file:

So we know how to avoid two inconveniences of the Java Runner (that we use due to our lack of practice of the Maven syntax):

1. A unique configuration file: Jenkins allows us to specify a different file for every Sonar analysis.
2. A much more practical and friendlier log every time we shall start one of our Sonar analyses.

This allows us great flexibility, especially in the organization of our environment of analysis. Let’s see two examples.

First, I will rename the sonar-project.properties as Myproject.properties, in the same directory ..\sonar-runner-1.1\Projects. I also modify the analyse release (sonar.projectVersion=1.2) in this file, in order to verify that this is this one that is taken in account.

Then, I will configure the Jenkins project with this file, before to start it again…Let’s check the result in Sonar: we now have a new version 1.2. This means that I can use a space ‘Project’ with as many configuration files that I have applications to analyze.

 

Another kind of organization is to dedicate a hard drive to my analysis environment, with an application folder in which I would locate both the source code of the application, but also any configuration file. In this second example, I will:

• Create a directory G:\Mainframe\MyAppCobol for my application.
• In this folder, create a sub-directory \Source where I will copy the Cobol programs to analyze.
• In this folder, create a sub-directory \Implementation\Conf where I will put the Sonar configuration file MyAppCobol.properties
• In this file, modify the property sources=G:/Mainframe/MyAppCobol/Source in order to specify the new localisation for the Cobol souce code.

Here is what my new environment looks like.

Finally, we modify the configuration of our Jenkins project to take into account the new Sonar configuration file, and run a new analysis.

So we can see that it is possible to organize analysis as we want, either by centralizing all configuration files within a single folder \Projects (for example) or by decentralizing each one at the level of the application.

We can handle as many analysis as we want, of any technology supported by a Sonar plugin, and use the Jenkins console to manage lofgs of analysis.

Finally, the implemented solution is based on the Java Runner Sonar without requiring any particular knowledge of other tools such as Ant or Maven.

 

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