[Buildbot-devel] Dependent schedulers not being triggered

Kenneth Lareau Ken.Lareau at nominum.com
Tue Mar 20 20:16:10 UTC 2007

Well, the good news is that I've figured out what's causing the problem
after a moment of clarity yesterday while talking with a coworker... the
bad news is I have no good solution for the problem I now face.

To recap, I have a large set of builders that are run on a nightly basis
via buildbot.  A set of those builders are on a dependent scheduler, but
for some reason they seemed to be not being run when their upstream was
succeeding.  Digging into the internals of buildbot via manhole showed
no issues...

The problem was user misconception in two different areas.  The first
was that the person who'd set up the dependent _scheduler_ (note it's
not plural) thought he'd actually set up a set of schedulers for each
product we support; that as not the case, as our schedulers are config-
ured one for each slave, not for each builder.  The reason for this is
our build system can't easily (or safely) do simultaneous builds (for
reasons I won't get into, but the system's limitation here is far, far
outweighed by its benefits).  The second was a misconception that if
builders in a given scheduler suceeded, related builders in the depen-
dent scheduler would also succeed; the documentation very clearly does
state this to NOT be the case.

So, now we know why the builders weren't being run; we have current
failures in builders which aren't being tested but are still part of
the upstream scheduler.  This leads to our current quandry: how to find
a way to allow a dependent scheduler to be selective about what succeeds
and fails in its upstream scheduler and run the appropriate builders
based on that information.  Is such a thing even possible?  Looking at
scheduler.py left me a bit lost, so anyone with a bit more experience
in this who can help would be greatly appreciated... including possibly
looking at how we handle our builds in a different way (though under-
standing our current build system might be a challenge in itself).

Thanks in advance for any help given...

Ken Lareau
Nominum, Inc.

More information about the devel mailing list