Menu

Subscribe

Hudson

For a while at work, we've been using the Hudson</a> continuous integration server for managing our builds. We use it in a couple different ways.


  1. 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.</li>
  2. 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." </li></ol>
    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.</div>

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

    </div>
    1. 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.</li>
    2. 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.</li></ol>