christian_unger at mac.com
Thu Oct 12 21:16:23 UTC 2006
thanks for explanation
what problem I am seeing with it?
It doesn't seem to have any effect,
I will try without calling init
On Thursday, October 12, 2006, at 09:22PM, Brian Warner <warner-buildbot at lothar.com> wrote:
>> 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
> class BuildCommand(Compile):
> 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