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.
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.