Background: I use Buildbot to run related-but-distinct builds on Linux and Windows. That is, the two builds together comprise "a build" for us; the products of both builds are what we care about. There are several synchronization points between the two builds, for example:
- we have a Java application that is compiled on Linux, but then bundled into
a Windows installer -- so we cannot run that part of the Windows build until the
Java build on Linux completes
- all of our applications (Linux and Windows) are ultimately packaged into RPMs by
the Linux build -- so we cannot run that part of the Linux build until all Windows
build steps complete
(Also, I'm not actually using Buildbot for continuous integration, but as a production build server. So I'm completely oblivious to schedulers, changes, and the like: all my builds are forced by external events, like QA tells me they need a build to test new features.)
My first attempt, many months ago, was to use the Dependent scheduler. This didn't work because I don't use schedulers at all. Even if I had arranged things to use schedulers (eg. with synthetic changes rather than forced builds), I would have needed a lot more than just 2 builders. I think every synchronization point would have forced a new scheduler and a new builder. I think I would have had something like 5 or 6 builders for my 2 builds with 3 synchronization points (can't remember exactly -- I never worked it out, I just ran screaming in horror).
So then I tried Dustin Mitchell's "trigger" patch (tickets 56 and 57). For a long time, I thought it would do the trick just fine. But it ended up falling down as well because each trigger can only trigger one scheduler. First, the use of schedulers as one end of a synchronization point means that again I would have to split my build up into 5 or 6 builders with almost as many TriggerableSchedulers?. Then, once I did that, I would have hit a wall: my "build RPMs" steps must be triggered by success of "linux C++ build", "linux java build", and "windows build". Bzzzt. Can't do that. Triggers don't work that way. Fail.
So I wrote Blocker, a new kind of build step that blocks its build until all upstream steps successfully complete. See attached patch. This is a surprisingly complex and subtle patch; if you start to read it, keep your wits about you and don't get distracted. Also, it's not done yet -- there's at least one sneaky bug in there that sometimes lets Blocker succeed even though one of its upstream steps failed. And the tests are inadequate, there's no doc patch, etc. Someone familiar with Buildbot internals should be able to find their way around from reading the comments and docstrings though.
I'm sharing it now to try to get some feedback from the community, see if anyone else needs such a build step, etc. Enjoy!
![[Buildbot Logo]](/trac/chrome/site/header-text-transparent.png)
