[Buildbot-devel] 'interlock' on bot?

[Brian Warner]

> if I (manually) start glib-full, will that mean glib-quick will also not 
> run until glib-full is completely done? (basicly, that is what I want. 
> regardless of the order in which builds start, I want only one at a 
> certain point in time).

The current interlocks are based upon Changes: the dependent build (the
"watcher") waits until the feeders have successfully built the same set of
Change objects as it wants to build. If you manually trigger a build with the
"force build" button, the interlocks are ignored. If you trigger one by
injecting a fake change, the usual timers and interlocks are used.

> BuildmasterConfig['interlocks'] = [ ("glib-lock", 
> ["glib-quick","glib-full"], ["glib-full","glib-quick"]) ]
> 
> But this might introduce a circular trigger (one one build starts, it 
> will never stop building again)

That would be.. bad. The interlocks only inhibit builds, they do not trigger
them, but that kind of circular interlock would deadlock and never allow a
build to begin. glib-full would not start building until glib-lock was
complete, but glib-lock can never complete until glib-full finishes building.

I sent the following text to Stephen in response to his one-build-at-a-time
question:

> My todo list has on it a note to turn the current Interlocks into
> "Dependency" objects (because that's what they really are) and create a new
> "Interlock" thing which simply states that only one of the participating
> builders can run at a time.. whoever grabs the Interlock first gets to run,
> and the others must wait until the Interlock is free. That should fix the
> spamming-the-overloaded-build-server problem.
> 
> Dependencies (which are currently mis-named Interlocks) can probably be used
> as a workaround. It isn't a great solution because the second build will not
> run at all if the first one fails, but it will serve to delay the second
> build until the first one finishes.

Dependencies worked for his situation because his second build was a debug
build, so it actually made sense for a failure of the regular build to
inhibit trying the debug run. It sounds like your environment really wants
proper Interlocks.

You can workaround it with dependencies (i.e. the current Interlock object)
by messing with the success/failure status. Each build is categorized in two
ways: a binary pass/fail indicator, and an Event that describes the build
(including color and text to be displayed in the top-most row of the
waterfall display). The Interlock class looks at the pass/fail indicator. You
could cheat and say that the first build "passed" but still put red in the
event box, to get the sequencing of the Interlock without the skip-on-failure
behavior.

Or, you could make an Interlock subclass which removes the skip-on-failure
code.

Or, you could prod me into finishing the Dependency/Interlock change I
described above :).

 -Brian