Let’s get serious for a moment, This tutorial covers the basic steps to set up Hudson continuous integration for a Perl project but it doesn’t cover it’s installation, not only because it’s a waste of time given the number of tutorials out there but also because it’s really simple, in my case I’ve followed the instructions for Debian right from the link in Hudson’s home page.

Assuming you have it installed with the default options you should be able to access to it by hitting http://localhost:8080 in your browser.

Main Screen

Now click in the New Job link located in the left part of the screen to launch the to Job’s Creation Wizard, there we need to select job’s name and job’s type, in my case I’ve called it MyProject and for Perl projects the project’s type is free style software project.

Project Creation

Continuing now click OK to finish the project creation. Now it’s time to start with project’s setup, click on Configure to jump into the configuration screen, there you’ll see a million options and I recommend you to click on the small icons with the question mark to bring the quick-help about them. First thing you need to configure is the source code repository, Hudson supports CVS and SVN out of the box but if you using Git or any other versioning system you can install plugins to use those.

As a sample project I’m going to use Template::Toolkit because author’s repository is publicly available and it’s a project with a considerable size. So in Source Code Management section select subversion and fill the URL and module

SVN Settings

Builds can be triggered manually, scheduled, by another job or by changes in the repository. In this tutorial we will use the last option so we have to specify how often we want the repository to be polled for changes, in this case I’ve chosen hourly.

SVN Polling Settings

Now the trickier part are the build steps, for Perl projects we’ll use shell commands, so click on Add build step button and select Execute shell from the drop-down menu.

Shell Command Settings

The following instructions may vary from project to project but the key part is that you have to ( at some point ) execute prove command. Hudson doesn’t now anything about TAP’s output but it understands JUnit’s output, so we have to transform one into another that is done using TAP::Formatter::JUnit.

Shell Command Settings 2

The test results output is piped to output.xml file and that file is then picked up by Hudson after each build to determine the build’s sanity, create charts and trigger other actions ( such as email notifications ). So in the Post build actions click on Publish JUnit test result report and specify the output file name output.xml.

JUnit Output

That’s it!, now click on Save at the bottom of the page. So, what about a test run??? Sure, why not? just click on Build Now … and …. voila!

Test results

As I said before Hudson has a lot of plugins and it’s very flexible, for example, it’s really simple to extend it to report test coverage using Devel::Cover or build perldoc> out of the POD included in the source files or run benchmark or profiling, the possibilities are unlimited it’s just a matter of being creative and playing with the options.

Perl has a new allied and it’s called Hudson!

comments powered by Disqus