warner-buildbot at lothar.com
Thu Oct 12 19:22:54 UTC 2006
> flunkOnFailure is a mystery to me,
> (how) is ths supposed to work (bb 0.7.4)?
What problem are you seeing with it?
If flunkOnFailure is set to True for a given step, then any failures in that
step will cause the build as a whole to be marked as failing. (I'm using
"flunk" here to mean "set the whole Build's state to FAILURE"). If it is set
to False, then a failure in this step doesn't cause the build to be flunked,
although some other failing step might flunk the build. Setting
flunkOnFailure=True is appropriate for a lot of buildsteps: if the compile
fails, the build has certainly failed.
There are other flags like this: warnOnFailure means that a failure of the
individual buildstep should mark the overall build as WARNINGS. This is
appropriate for nice-to-check-but-not-mandatory tests, like lint-checkers and
documentation generators that produce warnings.
haltOnFailure has the same effect on the build's overall status as
flunkOnFailure, but it also skips the rest of the build upon failure. This is
appropriate when there's no point in continuing after a failure, for example
a source checkout step: if you don't have any source code, there's no way you
can do anything else. Sometimes a compile failure should be marked
haltOnFailure, e.g. if you need compiled code to run the test suite.
Can you think of anything we could add to the user's manual section on these
parameters to explain this better? Or maybe they need to be added to an index
to make this section easier to find?
> class buildcommand( Compile ):
> def __init__( self, **kwargs ):
> command = ["/some/command", "ARG"]
> self.command = command
> Compile.__init__( self, **kwargs )
I usually write subclasses like this with class-level attributes, instead of
overridding __init__ . I always forget to do the upcall, and adding
attributes helps me avoid overridding a method at all. I'd write it like
command = ["/some/command", "ARG"]
flunkOnFailure = False
Or, you can just pass arguments to the base Compile command when you add this
step to your BuildFactory: it knows to set its flags based upon those
f.addStep(Compile, command=["/some/command", "ARG"], flunkOnFailure=False)
Of course, if you are going to use this BuildCommand a lot, it can be easier
to make the subclass. There are plenty of different ways to factor it.
More information about the devel