[Buildbot-devel] heads-up: internal changes

[Brian Warner]

> 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/
    master/
      Makefile
      buildbot.tap
      master.cfg
    master-support/
      buildbot@ -> ../buildbot-cvs

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

===============
PP= PYTHONPATH=~/Buildbot/master-support
tap:
	$(PP) mktap buildbot master -d $(PWD)
run:
	$(PP) twistd -no -l - -f buildbot.tap
start:
	$(PP) twistd -f buildbot.tap
restart:
        $(PP) twistd -f buildbot-shutdown.tap
stop:
	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
tap:
	$(PP) mktap buildbot master -d $(PWD)
        mv buildbot.tap buildbot-shutdown.tap
start:
	$(PP) twistd -f buildbot-shutdown.tap
stop:
	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.

thanks,
 -Brian