- We poll ClearCase for changes to the source, and kick off a build if there are any changes. This uses the SCM polling plug-in along with the the cron plug-in to check every hour or so to see if there are any changes. Based on the result from that SCM polling check, we kick off a bunch of other jobs that will do the actual calls to make to build our binaries.
- We have a nightly job that builds all the binaries (even if there haven't been any SCM changes) and then launches a series of sanity tests on the various platforms to make sure that the build is still "healthy."
We used to use a home grown solution that was tied very closely with make and specific options being passed, we quickly grew out of this solution.
There have been a couple of hurdles that we've had to overcome, but Hudson is extensible enough that is hasn't been too hard.
- Our SCM expert didn't like some of the ways the pre-packaged ClearCase plug-in worked, so he wrote some batch script tasks that did things the way he wanted them done.
- We wanted to keep track of the Hudson configuration in ClearCase, so that we could go back to a previous version of a job if need be. This was pretty easy for our SCM guy to implement as well. We just store the config.xml file for each job into ClearCase for each nightly build.
Hudson is one of the first open source projects I have contributed to. I wrote a simple plug-in to publish artifacts (things that are created during the builds) to a CIFS share. CIFS, for those of you who may not know, is the file system that Windows uses for sharing directories. So, to make it simple it allows files to be copied to a Windows share from either another Windows machine, or a Linux machine (or anything that jcifs works on).
Hudson is really nice. It is very configurable, and really easy to extend to implement what you need it to do. My next job at work is to try out SCons to see if it will work well as a replacement for make.