[Buildbot-devel] Dependent schedulers not being triggered

Bailey, Darragh dbailey at hp.com
Wed Mar 21 12:10:32 UTC 2007




> -----Original Message-----
> From: buildbot-devel-bounces at lists.sourceforge.net
[mailto:buildbot-devel-
> bounces at lists.sourceforge.net] On Behalf Of Kenneth Lareau
> Sent: 20 March 2007 20:16
> To: Brian Warner
> Cc: buildbot-devel at lists.sourceforge.net
> Subject: Re: [Buildbot-devel] Dependent schedulers not being triggered
> 
<snip>

> 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.

Instead of using a separate scheduler per slave to control your builds,
why don't you use slavelocks and masterlocks to limit the number of
builds being run.

Doing it that way also means that even if you force start the builds,
the locks will prevent the builds from being run at the same time. Which
is something that using dependent schedulers does not handle.


> 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...

What you really appear to be looking for is how to setup certain
builders so that if they fail it wouldn't affect the running of the
dependent scheduler.

I think that to get what you want you will need to write some custom
build steps and set the following variables appropriately.

    haltOnFailure = False
    flunkOnWarnings = False
    flunkOnFailure = False
    warnOnWarnings = False
    warnOnFailure = False

Look in the buildstep.py file for more details. You probably want to
make sure that for the builds that you don't care about, that the
buildstep that can fail has warnOnFailure set to true and haltOnFailure,
flunkOnWarnings & flunkOnFailure all set to false. 


Basically you can add a build step class to the master.cfg which ignores
the exist status of the command.

e.g.

class ShellCommandIgnoreFail(ShellCommand):
	flunkOnFailure = False
	warnOnFailure = True
	__init__(self, workdir, description, descriptionDone, command,
**kwargs)
		ShellCommand.__init__(self, workdir, description,
descriptionDone, command, **kwargs)
		

Look under the steps folder for other classes to extent and what class
variables to change.


One caveat, I've made some assumptions about how the *OnFailure &
*OnWarnings variables work, since I've never tested this sort of
behaviour before, but I think it should work for you.

--
Regards,
Darragh Bailey

Systems Software Engineer
Hewlett Packard Galway Ltd.
+353 91 75-4674




More information about the devel mailing list