In the first post of this new series about analysis of PL/SQL code with SonarQube, we have seen how I organize my analysis environment, with:
- a folder C:\SRC\ with all my projects,
- a sub-directory dedicated to each project,
- different other sub-directories, including one ‘..\Source’ containing the source code to be analyzed.
In the case of our PL/SQL analysis, this will therefoe be placed in the folder ’C:\SRC\Demo\PLSQL\Source’.
Let’s see no how to create and configure a SonarQube analysis of this code, with Jenkins.
Creation of the Jenkins job
I will present these steps precisely but without very much details or comments because we’ve done this many times already. I will of course make sure that the (Windows) services Sonar and Jenkins are started. Then we launch Jenkins, and in the main page, we will activate the link ‘New Job’.
In the page of creation of the new project, we will select the option ‘Build a free-style software project’ (or the corresponding option depending on the language you use with Jenkins).
We enter the new project name . Note that you can not use the name of an existing job.
Another approach would be to choose the option ‘Copy Existing Job’ to retrieve the configuration of an existing job, and then changing the parameters we wish to be different.
In the page of configuration of the project (‘Jenkins > PLSQL_Demo > configuration’ in my example), we will choose a unique ‘Build step’ (step in the execution of the job) that will consist of a Sonar analysis.
In this page, I will define all the parameters (properties) necessary to analyze our PL/SQL code with SonarQube.
I will not go into details, as we have already seen in the past several examples of analysis. Simply note:
- The mandatory parameters: key and name of the project, and its version. I can easily change this version number from Jenkins.
- The folder with the different sub-directories of our project : ’C:\SRC\Demo\PLSQL’, and in this folder, the sub-directory with the source code to analyze.
- And sure, the technology of this code, so that SonarQube can know wich ‘language’ plugin to use.
In the page http://docs.codehaus.org/display/SONAR/SonarQube+Project+Examples on the SonarSource website, you will will get different samples of ‘sonar-project.properties’ files for different technologies, so that you can avoid to forget a parameter.
And that’s it. We save the configuration of our job, we execute it … and then we just have to give a look at the results in SonarQube .
This we will do in our next post.