[Buildbot-devel] several slaves on the same host, starting them sequentially?
ttimo at idsoftware.com
Mon Aug 30 13:56:11 UTC 2004
On Sun, 29 Aug 2004 13:28:51 -0700 (PDT)
Brian Warner <warner at lothar.com> wrote:
> > I found the Interlock stuff, but it's a bit clumsy. I'd rather have
> > something that says 'single slave only has one build going at a time' ..
> Yeah, it isn't an idea solution for serializing operations like that.. it can
> work, but doesn't let you express what you really mean.
> My plan for this is to rename the current Interlock into "Dependency", since
> that's what it really provides, and then implement a new "Interlock" thing
> which behaves like a semaphore or lock: only one Builder can hold it at a
> time, the others wait for the first build to finish (success or failure)
> before grabbing the lock and running themselves. (maybe "Lock" is the best
> name for it). I think this would provide what you need.
> I probably won't get this into the next release (there are a lot of status
> improvements going in instead), but with luck it'll be in the one after that.
> Patches are welcome :). If you'd like to take a crack at it, look in current
> CVS at:
> new file and new class, should have methods like .get (which returns
> a Deferred that fires when the lock is available) and .release (which
> fires the next Deferred on the list)
> maybeStartBuild() should check to see if this Builder requires any Locks,
> use lock.get(), add a callback to start the build when it fires
> buildbot.master.BuildMaster.loadConfig_Locks: new method to take a lock name
> and a list of builder names which subscribe to it, create the Lock object
> and connect it to the Builders
> It is probably a good idea to only let each Builder wait on a single Lock, to
> prevent possible deadlocks. It might also be nice to do something more
> fine-grained (have the compile steps share one lock, and the checkout share a
> different one, letting you express that idea that you only have enough
> network bandwidith to support one checkout at a time, and enough CPU to
> support one compile at a time, but one build can be doing checkout while the
> other is compiling). That gets a bit trickier to implement, though.
> hope that helps,
Well .. I'm way too busy to spend a lot of time with the buildbot source
really. The main problem with InterLocks currently is that if one fails
the other ones won't trigger.. if that gets fixed, I have things basically
More information about the devel