You are here: Home Articles Using Hudson CI for Plone projects
OpenID Log in


Using Hudson CI for Plone projects

by Martin Aspeli last modified Aug 09, 2011 10:19 AM

Butler meets Chuck Norris

Using Hudson CI for Plone projects

Dexterity build test trending

In a previous life, I used the Hudson Continuous Integration server for Java projects. If you haven't heard of Hudson before, it's like Buildbot, but with a butler. It is also more user friendly and visually appealing.

If you haven't used continuous integration before, now is a good time to start. In any project, you should have a CI server set up that periodically runs your automated unit and integration tests. That way, you are notified immediately of any regressions you may have caused. This is particularly important in a team situation where you have multiple programmers working on the same code base. With CI, you can pinpoint which checkin broke the build (Hudson will tell you down to the revision, checkin message and author) and rectify it quickly.

Hudson will poll your source control system or react to external events (like you clicking a button or even an IRC message, if you have the right plugin installed), perform a build, and collect test results. It can distribute tests across several nodes, run builds in parallel, and integrates nicely with tools like Selenium and JUnit. Oh, and it can post your build status to Twitter.

Hudson is probably better known in Java circles, and has a bit of a Java slant, but the latest version is really rather nice. It's about as simple to get up and running as it could be, and it has a number of plugins, including ones that add the ability to execute Python scripts, various monitoring and reporting options, and that all-important Chuck Norris plugin:

"Chuck Norris doesn't need a debugger, he just stares down the bug until the code confesses."

And now, you can use it for your Plone project. Well, you always could, but collective.xmltestreport, a package I just released, provides a test runner that can output the types of XML test reports that Hudson expects to be able to produce pretty graphs and trending information about your tests.

It's pretty easy to set it all up. Download Hudson and start it up like so:

$ java -jar hudson.war

That will run Hudson on port 8080. See the Hudson documentation for more details on alternative ways of running the web server.

Then, log into the Hudson console and go to the "Manage Hudson" screen. Install a few plugins. I got plugins for:

  • Subversion
  • Monitoring
  • Plotting (graphing)
  • Selenium
  • Release
  • Tagging
  • Dashboard
  • Chuck Norris

The last one is particularly important, of course.

Then, create a new job. I used the "free-style" build template, specifying a Subversion URL to check out a buildout, a build trigger based on SCM polling, and an "execute shell" build step like:

cd dev # name of buildout
bin/develop up # update mr.developer sources
bin/buildout # re-build
bin/test --xml -s plone.dexterity # run tests

The build in question is the Dexterity development build. This has a [test] part which looks like this:

recipe = collective.xmltestreport
eggs = 
# other eggs in this list not shown
extra-paths = ${zope2:location}/lib/python
defaults = ['--exit-with-status', '--auto-color', '--auto-progress']

The recipe is a special version of zc.recipe.testrunner, which installs the test runner from collective.xmltestreport. This is the runner that adds support for the --xml (formerly -x, until zc.recipe.testrunner started using that flag for something else) command line option seen in the shell commands above.

Back in the Hudson configuration, enable "publish JUnit test results report" and set the report path to "dev/parts/test/testreports/*.xml". Here, "dev" is the name of the buildout). "parts/test" is created by buildout, and the "testreports" sub-directory is created by the collective.xmltestreport test runner when the --xml command line option is given.

Now, activate a build (or wait for Hudson to do it for you). You can watch the console in real-time performing the build happen, and then explore test results and build trends afterwards. It's pretty intuitive and you can get a lot of information about when a test started failing, how long it has been failing for, and what has been happening to your code since.

There is of course a lot more to Hudson. You can set up various notifications, and create multiple builds that depend on one another. You probably also want to set up some notifications (e.g. via email) when the build breaks. We also used to have Hudson jobs for things like resetting the test database (which we would run ad-hoc) and performing a health check on a live website (which we would run every ten minutes, and then all hell would break lose when it failed).

If you need to see what Hudson is doing, look in ~/.hudson. In particular, you will find the source checkout in ~/.hudson/jobs/<name>/workspace, unless you specified an alternative workspace location (which is useful if you want two builds to work on the same checkout, though you need to be a bit careful).

Document Actions

Good article

Posted by at Nov 16, 2009 02:43 AM
Thank you. A nice article to use Hudson CI.
Plone Book
Professional Plone 4 Development

I am the author of a book called Professional Plone Development. You can read more about it here.

About this site

This Plone site is kindly hosted by: 

Six Feet Up