[Buildbot-devel] On dependent vs. triggerable schedulers
Dustin J. Mitchell
dustin at v.igoro.us
Sun Jan 20 22:09:00 UTC 2013
You've identified the two best pieces we have right now to support
this kind of behavior, and some weaknesses of both. This is the
"build coordination" project.
A few relevant points:
* It turns out that "joining" builds - that is, trigger builder C when
matching builds for A and B complete successfully - is rather
difficult. It's hard to define "matching", and it's particularly hard
to filter out builds that will never be matched. Without such
filtering, you'll end up with a lengthy list of builds for A or B
waiting for a partner that will never occur.
* There are more ways of handling Sourcestamps in these situations
than any one person can imagine.
* A common way to structure this problem is to have a "master" builder
that only contains Trigger steps, and triggers other builders in the
proper order. This has the difficulties you've noted with handling
failures of component builds, and also ties up a slave for the master
builder without any activity taking place on that slave. A good fix
for this would be to allow builds to run without a slave, but that's a
pretty significant change to Buildbot's core.
At one point we talked about "fleets" of builds, where the fleet would
get a single identifier. The state of the fleet could then be handled
with a basic state machine -- simple to implement and easy to persist
to the DB. But hard to write.
There's certainly work to do here!
More information about the devel