[Buildbot-devel] Dependent schedulers not being triggered

Brian Warner warner-buildbot at lothar.com
Sat Mar 24 20:38:05 UTC 2007


"Bailey, Darragh" <dbailey at hp.com> writes:

> 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

These settings work exactly the way Darragh explained. For reference, I'll
add two notes about using them:

The first is that these parameters control the way that BuildStep results are
combined to determine the results of the overall Build. You can use these
parameters to, say, specify that your docs-building step is not critical, so
that failures in 'make docs' should not mark the whole build as failing. By
setting flunkOnFailure=False and warnOnFailure=True for that particular step,
the 'make docs' step could only downgrade the overall build to WARNINGS
rather than marking it as FAILURE. Likewise, if you have a ShellCommand that
does a compile, and you know that there's no point to running a long unit
test suite if the tree didn't even build, you can set haltOnFailure=True for
that compile step, which will cause the whole build to stop if that step
fails.

I mention this because I suspect that Kenneth has builds in his upstream
schedules that are failing for good reason, and he doesn't want to mask those
failures.. it's just that he wants to run the downstream builds anyways. I'll
talk about that issue in a separate message.

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

The second note is just to mention that you can set these parameters as
constructor arguments too, in addition to (or instead of) using class-level
attributes. For example:

 f.addStep(ShellCommand, command=["make","stuff"], flunkOnFailure=False)

The constructor arguments (in f.addStep) will override the class-level
attributes. ShellCommand has a set of defaults if you don't specify them
otherwise.. I think flunkOnFailure=True is one of them.

Using these arguments might be easier than writing a subclass.. depends upon
how frequently you have to do this sort of thing.


cheers,
 -Brian




More information about the devel mailing list