[Buildbot-devel] multiple build masters?

[jearl at airsource.co.uk]

> I have a scenario where, for portability of build/slave masters, I was
> thinking of using one master for build/test of a branch.  This means
> that when you create a new branch, you could easily copy the previous
> build/test master config file and change it slightly depending on the
> svn repo.

An alternative along similar lines that I've been playing with is: put the
build configuration for each specific project or branch in the repository
at the top level of the branch's sub-tree. The single master's
configuration file finds and exec's (in an appropriate dictionary) each
per-project/branch build configuration at startup time.

The dictionary informs the branch build configuration where it is in the
repository, from which it can probably work out if it is a branch, a
release, or just the trunk --- so just copying trunk to a new place
implicitly creates a new builder/scheduler.

The last step (which I've not quite figured out yet) is to watch the
change source(s) for changes to or additions of new project build
configuration files, at which point it knows it should reconfigure.

Is there a hook from within the master (ie not on the command line) to
initiate a reconfig or full stop/start cycle? If it's just a single
builder/scheduler pair that's known to have changed or need to be added,
would it possible to do (just) this on the fly, triggered by a scheduler?

> It seems like the ideal buildbot scenario is to have one master for
> everything, and just create different build factories per branch.

After some experimentation I've settled on the per-branch build
configurations including a scheduler and a builder for each branch, with a
short user-visible name. Maybe not the best for memory footprint, but more
foolproof and easier to customize for funny tree configurations than the
single-builder/scheduler multiple-branch approach.

John