[Buildbot-devel] heads-up: internal changes

Brian Warner warner at lothar.com
Fri Aug 27 16:49:45 UTC 2004

> From: Timothee Besset <ttimo at idsoftware.com>
> Great news. I had some new stuff planned for my buildbot setup, I guess I
> should do that with the new source. Is it possible to run the latest code
> and an older version as well? I don't want to touch my old setup until I
> have something working with the new stuff.

Yeah, just create a separate directory for the new-code master and give it
its own config file. You can either use the same slaveport (and the same
slaves) and only run one at a time, or use a different slaveport and a new
set of slaves.

My preferred setup is a bunch of directories like this:

      buildbot@ -> ../buildbot-cvs

Where 'buildbot-cvs' is a CVS checkout from sf.net . The Makefile usually
looks like this:

PP= PYTHONPATH=~/Buildbot/master-support
	$(PP) mktap buildbot master -d $(PWD)
	$(PP) twistd -no -l - -f buildbot.tap
	$(PP) twistd -f buildbot.tap
        $(PP) twistd -f buildbot-shutdown.tap
	kill `cat twistd.pid`

Then any python libraries that are specific to this buildmaster get put in
master-support/ (either the python packages themselves or a symlink to them).
The master.cfg file gets edited in place. Starting the master is a simple
matter of 'make -C ~/Buildbot/master start', which I like to put in a @reboot
cron job.

The master-support/ is also a good place to put Twisted and any other
libraries you want to use which might not be installed system-wide.

To set up a buildbot which persists across reboots, use something like the
following.. this insures that the saved state of the last run is used as the
initial state of the next run. (BTW, I'm looking for ways to improve this,
possibly by moving the persistent state out of the .tap file altogether):

PP= PYTHONPATH=~/Buildbot/master-support
	$(PP) mktap buildbot master -d $(PWD)
        mv buildbot.tap buildbot-shutdown.tap
	$(PP) twistd -f buildbot-shutdown.tap
	kill `cat twistd.pid`

Some of the interfaces may still be in flux: I learned a lot while rewriting
the status delivery classes, which influenced interface changes. As I add
more status classes in the next few weeks, I might learn even more. Let me
know your use cases and I'll see how they can best be accomodated.


More information about the devel mailing list