[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!
Dustin
    
    
More information about the devel
mailing list