Continous Integration with Hudson, GIT and Symfony 2

This week i’ve set up a continuos integration server for work. I’m quite amazed about it and how it will improved my future work.


In this post I want to explain how I managed to set up Hudson, with GIT and Symfony1.4. If you want to know more about certain details off the procedure you might want to check out the links at the end off this post.

Continous Integration?

For all the non tech-savvy readers off this blog follows a short explanation what this is all about: Whenever a programmer makes a change to a piece off software, there is the risk off introducing unintended side-effects and introducing problems that you never dreamed about. Writing bug-free software is nearly impossible but there are good strategies to find quite a few off them, before they make it into the live version.

Whenever we produce a piece of software is to write some tests to ensure that its working. These tests can be executed in an automated fashion.

While the product grows more and more tests are created and you end up with a suite off tests, that you can run each and every time you change something in the source code.

Unfortunately there are certain problems that occur:

  • The more tests you have the longer they take to run
  • (Good) Programmers are lazy people and don’t want to do the same stuff over and over again

Thats where Continuos Integration comes into play.

Continuos Integration means that whenever a member off the team produces a new chunk off code a tool builds the whole program and runs the whole suite off tests. If the tests fail – it complains.

This way, after a hard working-day you can be certain, that its very unlikely that you introduced horrible new bugs affecting other parts off the system. And if you made a mistake – well, at least you know when it occurred and its quite likely that you find an easy solution.

Hudson, Symfony and git

I found a great tutorial in the internet that showed me part off the solution. The rests I had to lean the hard way. That’s why I decided to share with you, how i installed the whole thing.

Basic installation

I started on an Ubuntu machine.

Hudon can be obtained via apt-get. Pretty simple 🙂

  • wget -q -O – | sudo apt-key add –
  • sudo echo „deb binary/“ > /etc/apt/sources.list.d/hudson
  • sudo aptitude update
  • sudo aptitude install hudson

Tada – Hudson runs off port 8080!!

Securing Hudson

This was, well, the tricky part I managed to lock myself out two(!!!!) times. Quite frustrating – but if you know what you do its actually simple.

securing hudson

If you DO manage to lock yourself out – go and edit /var/lib/hudson/config.xml and set true to false – good luck!

Installation off the GIT plugin

  • Goto http://hostname:8080/pluginManager/available
  • Search for git
  • Install the „Hudson GIT plugin“
  • Hudson will restart

Setting up the project


Give your project a name and select „Build a free-style software project


Now configure git. Notice that for github its NOT sufficent to just copy the clone url. You have to alter the URI a little bit. Something like ssh:// will do. Then enter the branch. In my case I use the integration branch.

In order for git to work you will also have to create a pair off new ssh-keys and add them into the ~/.ssh/ folder of the user hudson. After that upload your public key to github – remember you’ve done this once. So you’ll probably manage to do it without further details 😉

Then you will have to configure git. Use:

$ sudo su hudson
$ git config --global "Mister Default"
$ git config --global ""


Now enter 5,20,35,50 * * * to Build Periodically and 0,15,35,45 * * * into Poll SCM. This will pull your branch every 15 minutes and start a build 5 minutes later. Feel free to come up with something better here 😉


Now we have to enter the steps necessary to create a new database, compile the model, filters and forms, load some test-data, execute the test and export the results into an xml-file. This sounds easy, but it took me a while to get this working.

  • rm $WORKSPACE/config/databases.yml
  • php $WORKSPACE/symfony configure:database –name=doctrine –class=sfDoctrineDatabase „mysql:host=localhost;dbname=myproject“ dbuser dbpass
  • php $WORKSPACE/symfony doctrine:build –all –no-confirmation
  • php $WORKSPACE/symfony doctrine:data-load
  • php $WORKSPACE/symfony test:all –xml=log/build.xml

Note: You will a running MySQL Database and (probably) you will need to export a database with php symfony doctrine:data-dump to have some test data (eg) categories.


Last but not least: Hint Hudson to the results and turn on Notifications. If you feel like it enable your Nabaztag 😉 (after downloading the plugin)


Hit Build now and see what happens. If the build fails, select it in the Build History and have a look at the console output and fix the problem. If you find its a problem with this description – leave me a comment. If it works – leave me a comment.

Lesson’s learned

This took quite long. Each and every single step is quite logical – but figuring out the combination was frustrating. It took me 3 hours to get the whole thing to work.

If Hudson will be a great help? Well lets see. After some days of using it I am quite pleased. For example it discovered some issues, that the tests on my MacBook did not uncover. Had something to do with case-sensitive vs. case-insensitive filesystems. I might actually become an even better programmer.. PLUS: Its a good feeling to have an objective, continuos indicator of ones work’s quality.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

2 Gedanken zu “Continous Integration with Hudson, GIT and Symfony

  • Kamil Kisiel

    You don’t really need to have both „Poll SCM“ and „Build Periodically“ enabled. Poll SCM will automatically trigger a build of your project if it has changed. I set up most of my projects with polling set to

    */5 * * * *

    to check every 5 minutes for changes.

    Then I usually add @midnight to do a nightly build so that all projects are built at least once a day, to account for any possible environment changes.