> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of
> On 3/20/06, Peter N. Lundblad <firstname.lastname@example.org> wrote:
> > Lieven Govaerts writes:
> > [...]
> > > 6. I'm not going to activate the option to send mails to
> > > committers who make the build fail :)
> > Ha, why not? :-)
> > Seriously, we could maybe arrange for some notification to the
> > breakage@list. 'cause I'm not going to poll a web page for
> this info.
> I'm actually in favor of sending mail to both the committers
> who caused the breakage and the breakage@ list, but before we
> do that we should at least get the tests that are running
> under buildbot to pass once ;-)
That's step 1, I'm working on that. In fact, I brought the Mac build offline
and fixed the FC1 build, that one is running fine now.I propose to start
with sending emails to breakage@ first. We can add some other slaves, which
probably requires some new configuration and let that stabilize for a while.
If that works, we can start sending mails to committers. There's an option
to ping an IRC-channel as well, didn't test it yet though.
> > > 7. I've installed a TryScheduler as well. The
> > > TryScheduler is used to trigger manual builds, with custom patches
> > > committed to the svn repository: "What would happen if I committed
> > > this patch right now?".
> > > To use the TryScheduler, developers need the buildbot client and a
> > > username/password to connect to the buildmaster.
> > This sounds like one of the most useful features of this system.
> Agreed ;-)
It is, and I'm sure this was the very reason why buildbot was tentatively
selected as the tool for the Subversion B&T farm.
> > The TryScheduler checkouts trunk and applies the patch, but in this
> > example it fails to make the path_tests.py executable, so the test
> > won't run.
> If it turns out to be overly annoying we could also look into
> other mechanisms of running the tests, via python explicitly
> instead of actually running them directly, for example.
It probably isn't that difficult to fix, I'll have a look at it. It's not
high priority either.
> > This all sounds very great! I currently run nightly tests
> for 1.3.x.
> > It would be nice to try being a slave for all trunk and
> other active
> > branches as well. Where do I find out how to set up a slave?
> I'd also be interested in setting something up.
I'll write some things down on how to install a buildbot slave. The page
http://subversion.tigris.org/build-farm.html already explains a bit. My
setup is slightly different though, my steps ( checkout, autogen,
configure... ) are configured and triggered by the buildmaster. It's
probably better to bundle that in one script on the slave, so that the
buildmaster only has to trigger that script.
> One suggestion I've got for the failure page is that if we
> could possibly make the tests.log files available to through
> the buildbot interface it would be much easier to debug test
> failures on remote slave boxes.
Yep, I think that's really needed, otherwise it will be up to the buildbot
slave owner to solve those issues. I'm setting up a location on my server
where those files can be FTP'ed to, so they are accessible by webbrowser
I'll provide a script to the slave owners for this upload. That script can
then also print out the name & url of the log file it ftp'ed to relate a
build and its logfile (output of scripts are visible in the buildbot
But now first thing I'm going to do is get that Mac OS X build working.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Mar 21 19:48:32 2006