{"id":80,"date":"2011-12-28T17:35:32","date_gmt":"2011-12-28T16:35:32","guid":{"rendered":"http:\/\/dev.qualilogy.com\/en\/?p=80"},"modified":"2013-01-04T17:37:09","modified_gmt":"2013-01-04T16:37:09","slug":"sonar-cobol-analysis-with-jenkins","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/en\/sonar-cobol-analysis-with-jenkins\/","title":{"rendered":"Sonar – Cobol analysis with Jenkins"},"content":{"rendered":"

We saw in the previous post<\/a> 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<\/a>. <\/p>\n

\"\"<\/a>For this, we will create a project from the main page of Jenkins.<\/p>\n

In the creation page, we enter a project name and select the first option: \"\"<\/a><\/p>\n

This opens the configuration page of this project, in which we say that we want a Sonar analysis:\"\"<\/a><\/p>\n

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

\"\"<\/a>But first, we will enter a new version into this configuration file: sonar.projectVersion=1.1<\/strong>.<\/p>\n

\"\"<\/a>Don’t forget to save the parameters of this project.<\/p>\n

Before to start it.\"\"<\/a><\/p>\n

\"\"<\/a>And while it is running…<\/p>\n

 <\/p>\n

\"\"<\/a>We can have a look to the log:<\/p>\n

\"\"<\/a>Then look at the result of the analysis into Sonar, with the version number indicated into our configuration file:\"\"<\/a><\/p>\n

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):<\/p>\n

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

    This allows us great flexibility, especially in the organization of our environment of analysis. Let’s see two examples.<\/p>\n

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

    Then, I will configure the Jenkins project with this file, before to start it again…\"\"<\/a>\"\"<\/a>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.<\/p>\n

     <\/p>\n

    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:<\/p>\n