[Buildbot-devel] flunkOnFailure

[Christian Unger]

Hi Brian,

thanks for explanation
what problem I am seeing with it?

It doesn't seem to have any effect,

I will try without calling init


cu
christian unger

 
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?
>
> http://buildbot.sourceforge.net/manual-0.7.4.html#Common-Parameters
>
>
>> class buildcommand( Compile ):
>> 	def __init__( self, **kwargs ):
>> 		command = ["/some/command", "ARG"]
>> 		self.command = command
>> 		self.flunkOnFailure=False
>> 		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
>this:
>
>  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
>arguments:
>
>  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.
>
>cheers,
> -Brian
>
>


cu
______________
christian unger