WO Blog

Hudson and Symfony continuous integration

We’ve been experimenting this week with using Hudson as our continuous integration server for our latest Symfony project.  Previous experiences with CruiseControl via phpUnderControl and the symfonyUnderControl plugin were OK-ish but we’d occasionally experience CruiseControl dying on us with no warning apart from the lack of emails after checking our code in.

So we decided it was time to perhaps investigate alternatives.  The obvious choice for Symfony would be to use Sismo, but sadly it hasn’t been released yet… Fabien, any clues as to a release date? ;-) It looks at the moment as if we’re stuck with a Java-based solution, so we decided to look at Hudson as an alternative.

Setting up Hudson was straightforward using Nicolas Perriault’s blog post on exactly what we were trying to achieve, linking in with our Subversion repository.  The configuration of the projects took a bit of faffing – for some reason, Hudson liked to check out the whole repository rather than just eg the trunk folder  as specified, so this screwed up some of the paths.  A bit of trial and error later and we were up and running with a build every 30mins if there are new commits, as this pretty graph shows… (using the jUnit XML output available in Symfony 1.4).  Total number of tests in blue, failures in red.

Hudson build trend output

One thing to bear in mind if you’re getting test failures randomly, or perhaps always after a certain developer checks in (and it’s not a result of broken code) is to ensure that the permissions are correct for Symfony, as SVN likes to store permissions where it can.  The fix for this, apart from committing new permissions, is to add a build step in Hudson that carries out ./symfony project:permissions (Symfony 1.3+) shortly before the build.  This seems to solve it nicely, and explained the small red peaks in the graph above.

3 Comments

  1. xzyfer
    Posted 10 March 2010 at 12:40 pm | Permalink

    i am looking to implement a similar solution for my company’s new symfony project.

    question for you:
    are you using phpunit or just lime?
    is you are simply using lime, do you find it extensive enough to cover you testing needs?

  2. Rich
    Posted 10 March 2010 at 12:49 pm | Permalink

    We use Lime, as obviously it comes with Symfony and it’s got a pretty low entry barrier to getting started and using it for tests. In particular, the functional tests are the aspect that is probably the most useful for us. It’s definitely extensive enough for projects we’ve done – at the end of the day, the methods available in Lime will cover most of what you’ll need to do in your unit and subsequent functional tests so it’s been great for us.

  3. Posted 30 September 2010 at 12:56 pm | Permalink

    We are using Hudson to manage a bunch of custom builds and like the quickness afforted by Hudson in configuring a build. One of the issues we are trying to resolve is when there are two different branches involved in producing a build. For example, many of our products use a common library, and occasionally a new branch of that common library is needed, along with the branch of a module (different modules). It appears that Hudson’s CVS setup only allows us to identify one branch, when what we need is a second CVS setup to identify an additonal branch.

    Does anyone know how to handle such a situation?

Post a Comment

Your email address is never published nor shared. Required fields are marked *

*
*