[Buildbot-devel] Serializing builds

Brian Warner warner-buildbot at lothar.com
Fri Nov 12 22:27:20 UTC 2004

> A question about interlocks:
> If I have to pass the interlock to a given builder, why must I specify the
> watcher-list? It would seem like the builder would be able to get by with
> just a feeder list, assuming that the interlock is passed to all the
> builders which appear on the watcher-list. Or is it designed so that I must
> pass the same interlock to both the watcher and the feeder builders?

Interlocks are somewhat like edges on a graph where the nodes are Builders.
(except that each Interlock can have multiple inputs and multiple outputs).
Interlocks are separate objects that attach themselves to their 'watcher'
builds and inform those targets that they aren't allowed to start until the
interlock says so.

If the Interlock functionality was more built-in to the Builder, then yeah,
it would be a question of telling the target Builders which of the source
Builders they have to wait upon. The implementation happens to be the other
way around, though, so the Interlock runs separately and sticks its tentacles
into both the feeder (input) and watcher (output) builders. Therefore you
give the Interlock a (feeder,watcher) pair of lists of Builder names, and it
does the rest.

Each Interlock also has a name, which is used in the status display to
explain what the builder is waiting for.. after it moves from the "waiting"
status (meaning the tree-stable-timer is still running), it may go to an
"interlocked" status (meaning the Interlock hasn't given it the go-ahead
yet), and in that state the interlock's name is displayed to make it clear
what needs to happen before it can start building.

The c['interlocks'] config directive is then a list of 3-tuples: (interlock
name, feederlist, watcherlist).


More information about the devel mailing list