Grails & Hudson / Jenkins Part 6: Sonar

sonar is an open source code quality management tool – this requested addition to the grails & hudson / jenkins series gives a quick run through of how to set up sonar to analyse grails code from a jenkins job.

sonar
download the latest version of sonar (currently 2.9) from http://sonar.codehaus.org/downloads/
the installation instructions are here , but for speed of evaluation you can just unpack the zip.

before we start up sonar, we’ll need to install the groovy support.

sonar groovy plugin
download the latest version of the jar (currently 0.3 ) and copy this to $sonar_home/extensions/plugins .

now start up sonar, run the $sonar_home/bin/<os>/sonar.sh (or startsonar.bat on windows)
make sure sonar is running on http://localhost:9000

jenkins

jenkins sonar plugin
the first thing to do is to install the jenkins sonar plugin following the process outlined in part 2 of this series :

• from the main dashboard, click on “manage jenkins”
• click on “manage plugins”
• go to the available tab, find & select ‘sonar, then click on the install button.

when the plugin has downloaded and installed, you will need to restart jenkins.

configure sonar
this is easy as we’re using the default settings.

• click on ‘manage jenkins’, click on ‘configure system’
• scroll down to the sonar section
• click on the ‘add sonar’ and enter a name such as ‘localhost’ (that’s it if you’re using the default sonar port on the same machine).

in the ‘advanced…’ settings shown in figure 1, you can set alternative server urls etc. and set the global trigger settings.
in this case, i’ve enabled sonar to run on ‘poll scm’ triggered builds (i.e. after code has been checked-in).

figure 1: sonar global configuration

configure sonar post-build action on your job

go to the job configuration page and scroll down to the ‘post-build actions’.
check ‘sonar’ – you can also override global triggers as shown in figure 2.

leave the ‘check if this project is not built with maven 2.’ checkbox unselected.

figure 2: sonar job configuration

pom-pom, tiddly-pom
sonar utilises maven, so we’ll need a pom.xml if the build isn’t already mavenised. the pom needs to instruct sonar that the language is groovy
before non-maven users get too concerned, there is a sample on the sonar groovy plugin page – or you can use/adapt the custom grails sonar pom script (put it in the scripts directory) to create a pom.xml for your grails project:
grails create-sonar-pom
you can either supply the groupid or it will prompt you for one.
when the script has finished you’ll see:
pom for sonar groovy created: /path/to/pom.xml

examine the pom.xml – you may want to adjust the ‘sourcedirectory’ settings (as the todo in the script says to prevent ‘conf’,'controller’ etc. being treated as packages by sonar).

we’re now ready to run the jenkins job. the first time will take a while as maven seemingly downloads the internet.
when the job has finished, you’ll be able to click on the sonar link from the job (figure 3) to get to sonar (figure 4) and then onto the project dashboard (figure 5).
note the link is at the job-level rather than the build-level as sonar maintains a historical view of project metrics. also the build history will include the sonar icon to show which builds have been analysed by sonar.

figure 3: sonar link

figure 4: sonar homepage

figure 5: sonar project dashboard

hopefully that has answered david’s question and given a good taster of using gmetrics and codenarc via sonar (i’m not a sonar expert by any means, so welcome any improvements!).
lastly i think it would be good to get the sonar metrics exposed through the jenkins violations plugin (as mentioned on https://wiki.jenkins-ci.org/display/jenkins/sonar+plugin ).