Some Ruby developers have found Hudson to be a much easier to use and more powerful alternative to cruisecontrol.rb. It is implemented in java, but that doesn’t make it a less compelling option (after all jruby is written in java). See http://blog.mat…

http://slowtwitch.de/wp/2008/12/hudson-nabaztag-publisher-plugin/

Have Phun
Stephan

We have our own branch at http://github.com/songkick/testjour/tree/master but I don’t think it has anything particularly special in it – you should be able to use Bryan’s branch just fine.

We don’t use github for our main application code – again we just run a git repo in-house, so I’ve never needed to try the hooks. We just get hudson up to poll the repo for changes every minute, which is good enough for us. I’m happy to hear there’s a github plugin though. Want to post back here when you’ve tried it and let us know how it works?

I will also probably give Hudson a shot. I’m going to bump my CI slice up to 1GB and see if it runs in that. The incremental cost is ok. Looks like Hudson supports GitHub post-receive hooks via a plugin someone has on GitHub, you guys using that?

We run Hudson on in-house hardware, so we have the luxury of being able to add RAM fairly cheaply. Here’s the output from ps on our build server:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
hudson    4821  2.0  6.4 1553652 249600 ?      Sl   Aug05 431:43 /usr/bin/java -jar /usr/share/hudson/hudson.war --webroot=/var/run/hudson/war

So it looks like we need about 1.5GB to run our Hudson. YMMV.

For running testjour slaves, we use this in our rake task:

def runfeaturegroup(feature_group)
  slaves = []
  slaves << "--on=http://hudson@of1-dev-buildslave1.srv.songkick.net:15434/var/lib/hudson/skweb"
  slaves << "--on=http://hudson@of1-dev-buildslave2.srv.songkick.net:15434/var/lib/hudson/skweb"
  slaves << "--on=http://hudson@of1-dev-buildslave3.srv.songkick.net:15434/var/lib/hudson/skweb"
  slaves << "--on=http://hudson@of1-dev-buildslave4.srv.songkick.net:15434/var/lib/hudson/skweb"

# profiles are defined in cucumber.yml
  # subsystem profile excludes filestore features from the build
  sh("testjour #{slaves.join(" ")} -p #{featuregroup} --max-local-slaves=0 features/cucumber/#{feature_group}")
end

I’d advise having a look at the testjour code if you’re not sure what it’s doing – it’s still pretty immature and not especially well documented yet.

I am also in the middle of setting up Testjour, and that’s how I came across this blog entry, as I’m having some issues simply starting up slaves. Do you have the correct command line vs. what’s documented? i.e. I’ve found I need to use “testjour run:slave”, instead of the “start:slave” in the README, but it seems to want a URL as well?

Agreed Aaron – I just recently needed a build server to run on the Dreamhost shared host this blog runs on, and the Dreamhost admins kept killing hudson because it hogged too much RAM! Integrity fitted the bill nicely in the end (though getting a sinatra app running on Dreamhost was a world of pain).

You’re right it should be easier to delegate builds to a 3rd party. http://runcoderun.com/ are having a good crack at it.

If you have a LAMP (or Rails) hosted or VPS build server, then you might be hesitant to take the memory and CPU hit. I’m working on a way to make it easier to get a dedicated build farm running.

Wouldn’t it be nice to have an account somewhere that could run CI and even parallelize build and testing out? I want to work on something like that