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.
Before we start up Sonar, we’ll need to install the Groovy support.
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
- 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.
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
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:
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).