[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 mailing list