kfogel@collab.net wrote:
> Just to let you all know: I'm working with CollabNet's operations team
> to set up a small build/test farm for Subversion. Erik Hülsmann first
> proposed this idea privately at EuroOSCON in Amsterdam, and when we
> took it to CollabNet they were in favor right away.
>
> The goal is to have stable, consistent environments for verifying that
> releases (and bindings) work on certain platforms. Right now we've
> got a box each allocated for Linux (probably RHEL4 or FC4) and Windows
> XP; next in line are Solaris 10 and Mac OS X, but we'd like to get the
> Linux and Windows instances up and running first.
>
> WHAT YOU CAN DO TO HELP:
>
> These boxes will be managed by CollabNet's operations team, but
> they'll be configured according a specification that the Subversion
> project writes. I'll be starting that specification in our www/ area;
> anyone who has experience with such systems, please help out. The
> better our spec, the more easily (== the more quickly) CollabNet can
> set up the farm.
>
> Erik Hülsmann, Sander Striker and I discussed various build/test
> systems in Amsterdam, and came up with this short list of candidates
> (Erik, Sander, did I leave out anything major?):
>
> * BuildBot
> https://sourceforge.net/projects/buildbot/
> http://buildbot.sourceforge.net/manual-0.7.0.html
>
> * GUMP
> http://gump.apache.org/
>
> * Tinderbox
> http://www.mozilla.org/tinderbox.html
>
I don't know about the other two, but keep away from tinderbox. I tried
installing it once, and it's an even worse mess than Bugzilla.
(Unless you like weeks of pain and sleepless nights, in which case, be
my guest. :)
> If you have experience with any of these, or if you favor another
> system, please follow up.
>
I've been using CruiseControl (well, CC.Net on Windows, really) --
http://cruisecontrol.sourceforge.net/ -- and found it quite nice. I
don't think it can handle uncommitted changes, though.
> ABOUT TESTING UNCOMITTED CHANGES:
>
> These boxes will not only be for testing trunk and release tags, but
> for testing uncommitted changes -- say, changes that fix the bindings
> on Windows when they're broken and those who have the expertise to fix
> them don't have access to a Windows box (to pick a totally random
> example, ahem).
>
> Even though we won't have login access to these boxes, at least one
> system, BuildBot, has a feature that allows a client instance to do a
> patched build, see
>
> http://buildbot.sourceforge.net/manual-0.7.0.html#try
>
> (Thanks to Erik for digging that up.)
>
> Because of this feature, and because of BuildBot's documentation and
> portability (see http://buildbot.videolan.org/), I'm leaning toward
> BuildBot right now. However, real-world experience is the best data,
> so if anyone here has any, this is the time to speak up.
>
Unless buildbot is noticeably worse in other areas, the
uncommitted-change thingy is a huge feature. Other than that, there are
two "must" features that such a build tool should have:
* It must integrate well enough with SVN to know when to skip a
build due to there being no changes in the repository.
* It must be able to send mail to everyone who committed a change
that may have broken a build (that is, everyone who committed
since the last successful build).
The second item is important because (I suspect) many committers still
don't subscribe to svn-breakage.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 6 03:02:26 2005