[Buildbot-devel] several slaves on the same host, starting them sequentially?

Timothee Besset 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:
> 
>  buildbot.process.lock.Lock:
>   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)
> 
>  buildbot.process.builder.Builder:
>   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,
>  -Brian
> 

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
working already.

TTimo




More information about the devel mailing list