Sonar and Continuous Integration
My previous blog was about Sonar – the open source code quality management tool. Deploying Sonar in a machine, and then running it manually for every code change is not desirable for many of us. Definitely there must be an automation step possible, to run Sonar whenever there is a change in the code base. It would be really wonderful if a nightly build or a weekly build software can trigger Sonar, and just publish reports about the violations in the code changes recently done. I never expected it be more easier than integrating Hudson with Sonar. Hudson is a widely used continuous integration tool, that works with any kind of version control software like CVS, VSS, SVN, Clear Case, etc.
Hudson is another web based tool where various types of projects can be scheduled to build in any specific interval. Hudson supports projects with Maven, Ant and those do not have any build script as well. It is quite simple to setup Hudson, just download Hudson and start using the command: java –jar hudson.war.
Before configuring a project, install the Sonar plug-in for Hudson from Dashboard –> Manage Hudson –> Manage Plugins –> Available plug-in list. Hudson must be restarted for the plug-in to be applied.
To setup a project in Hudson, create a New Job from the dashboard. Provide a job name and select what type of project needs to be created.
The next page shows up is the job configuration. There are several options that can be configured, from source code management software, build triggers, build settings and post build actions. The post build actions feature Sonar which must be enabled for Sonar to run automatically after the build is complete. Sonar configurations can also be changed appropriately.
There is a little manual configuration that needs to be done here. The maven project configuration in Hudson does not allow you to specify an absolute path for the pom.xml to be used to build the project. When the project configuration is saved, a workspace directory is created. The pom.xml file used for the project build must be manually copied to the workspace directory for Hudson to perform the build. I wished there is a configuration to specify the pom.xml from any directory. Unfortunately no! Once all the configurations are done, its time to build the project.
From the Hudson dashboard, click on the project name and then do a Build Now, and the project build starts. A progress bar is shown when the build is in progress. Once build is successful, the build history is updated with the build results.
Now the Sonar dashboard can be accessed to view the updated reports. Sonar over-writes the reports that were generated earlier for the same project. So, to compare results of build history, the version in pom.xml must be changed every time manually before the build.
The integration between Sonar and Hudson has been very simple and without much manual work. But still more exploration is needed to find out how Sonar can show incremental differences in the violations rather than over-writing the entire report.
With a whole lot of plug-ins and ease of use Sonar, Hudson & Maven can provide a complete build process solution for any organization.