Re: [nant-dev] Bug? <fail/> task doesn't work as expected whencalled within a nant.onsuccess target

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi,

Backwards compatibility with existing scripts was something that also =
occurred to me, and I have been trying to think of ways to achieve what =
I want without sacrificing backwards compatibility, and I came up with =
two alternatives:

1. Provide a new 'failonerror' property on targets. To maintain =
backwards compatibility, this should default to 'true' for 'normal' =
targets, and default to 'false' for onsuccess and onfailure targets. =
Then all I'd need to do is override the default value on my custom =
on-success target, setting it to 'true'.

2. Provide a new 'errorcode' attribute for the fail task. More =
generally, this attribute could be associated with all tasks, which =
would be honoured if the task fails. Even though the <fail/> task =
invoked in an onsuccess target doesn't unwind the build, it could still =
be used to set the exit-code of the NAnt process.

Chris

-----Original Message-----
From: Martin Aliger [mailto:mar...@go...]=20
Sent: 15 November 2007 11:32
To: Chris Lambrou; nan...@li...
Subject: RE: [nant-dev] Bug? <fail/> task doesn't work as expected =
whencalled within a nant.onsuccess target

Hello,

I think, your use of onsuccess is somewhat strange, but I sill side with =
you. It seems reasonable to return fail code when something in the =
onsuccess fails. Only thing I'd be afraid of is backward compatibility.

Since NAnt is often used from 3rd party software (like CCNet) it is very =
important to return right exit code. So this case has my +1 vote.

Btw: CCNet default web pages highlights all messages with level Error or =
those containing text "Error" as errors. So you can log your non-fatal =
errors with <echo> task. Still - build is considered as successful in =
this case. Failonerror NAnt attribute also makes non-fatal error from =
fatal ones.

Ing. Martin Aliger
mar...@go...=20

-----Original Message-----
From: nan...@li...
[mailto:nan...@li...] On Behalf Of =
Chris Lambrou
Sent: Wednesday, November 14, 2007 12:46 PM
To: nan...@li...
Subject: Re: [nant-dev] Bug? <fail/> task doesn't work as expected =
whencalled within a nant.onsuccess target

Gert,

If the main build outcome is successful, but the onsuccess target then =
fails, I think there's a very good case for this resulting in overall =
failure of the build. It's certainly what I expected to happen, anyway =
[perhaps because I mentally assumed that the onsuccess target would be =
invoked from within a finally clause wrapped around the main build, and =
raising an exception in the finally clause would cause a failure =
overall].

If the main build raises a BuildException, and the ensuing onfailure =
target also raises a BuildException, then as long as both are properly =
logged, nothing would be hidden. NAnt would still terminate with a =
non-zero exit-code, of course.

Chris

-----Original Message-----
From: nan...@li...
[mailto:nan...@li...] On Behalf Of Gert =
Driesen
Sent: 13 November 2007 19:17
To: Chris Lambrou; nan...@li...
Subject: Re: [nant-dev] Bug? <fail/> task doesn't work as expected =
whencalledwithin a nant.onsuccess target

Chris,

I'm not sure this is something we should "fix".=20

If we do this, then we should do it for both onsuccess and onfailure. We =
then risk hiding the original build outcome.

Gert

-----Original Message-----
From: nan...@li...
[mailto:nan...@li...] On Behalf Of =
Chris Lambrou
Sent: maandag 12 november 2007 16:53
To: nan...@li...
Subject: [nant-dev] Bug? <fail/> task doesn't work as expected when =
calledwithin a nant.onsuccess target

Hi,

I recently posted an issue on the nant-users list, but I think the =
underlying issue is one for this list. The problem is that the <fail/> =
task doesn't cause NAnt to terminate with a non-zero exit-code when =
executed from within a target defined by the nant.onsuccess property. I =
think that it should always result in a non-zero exit code (with the =
possible exception of when a BuildException is explicitly caught by the =
trycatch task from nant-contrib).

The scenario is that I'm using CruiseControl.NET to run a NAnt script as =
part of a continuous build process. There are two conditions under which =
CCNET needs to consider the build a failure:

1. Fatal errors: Typically this would be a compilation error. This is =
considered fatal, as my build script cannot proceed further. In this =
case, the relevant NAnt task will fail, the BuildException causes NAnt =
to unwind and it terminates with a non-zero exit-code. CCNET detects =
this exit code, and considers the build to have failed.

2. Non-fatal errors: This is where a condition is detected that should =
result in CCNET considering the build to be a failure, but no specific =
task in the NAnt script actually fails, and the script can nonetheless =
proceed to completion, whereby NAnt would normally terminate with an =
exit code of zero.
Typically, such a compilation error might be an FxCop rule violation, or =
a unit-test failure.

In the case of non-fatal error, I'm trying to force the NAnt script to =
fail using the technique illustrated in the following build script =
(attached), that shows three different cases:

1. Case 1: This simply illustrates NAnt running successfully.
2. Case 2: This is the typical use of the <fail/> task to cause a fatal =
build error.
3. Case 3: This is how I wish to deal with non-fatal errors. The "case3"
target modifies a property to indicate that a non-fatal error has =
occurred, but script execution continues. After the rest of the script =
has completed, the "on-success" target checks the "error-message" =
property, and tries to <fail/> the build if a non-fatal error was =
detected.

    <project name=3D"NAnt bug" =
xmlns=3D"http://nant.sf.net/nant-all.xsd">

        <property name=3D"error-message" value=3D""/>
   =20
        <target name=3D"case1">
            <echo message=3D"This target should result in an exit-code =
that indicates success."/>=20
        </target>
   =20
        <target name=3D"case2">
            <fail message=3D"This target should result in a exit-code =
that indicates failure."/>
        </target>
   =20
        <target name=3D"case3">
            <echo message=3D"This target should result in a exit-code =
that indicates failure."/>
            <property name=3D"error-message" value=3D"Non-fatal =
error."/>
        </target>
   =20
        <property name=3D"nant.onsuccess" value=3D"on-success"/>
        <target name=3D"on-success">
            <fail message=3D"Failure forced"
if=3D"${string::get-length(error-message) > 0}"/>
        </target>
    </project>

The following batch script can be used to run the three different cases:

    nant case1
    echo Error-level: expected 0, actual %errorlevel%
    nant case2
    echo Error-level: expected 1, actual %errorlevel%
    nant case3
    echo Error-level: expected 1, actual %errorlevel%

Cases 1 and 2 work just fine. Case 3 should display this,

    Error-level: expected 1, actual 1

but it actually displays this:

    Error-level: expected 1, actual 0

In case 3, because NAnt terminates with an exit code of zero, CCNET =
assumes that the build was successful, when in fact I want CCNET to =
consider the build a failure. It's my guess that the problem isn't =
specific to the <fail/> task - NAnt is probably consuming any =
BuildException that may be raised by the on-success task. I think that =
this is an error. If there's an error in the on-success target, the =
build should fail, even when the main execution of the build script was =
successful.

Chris

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.503 / Virus Database: 269.15.31/1129 - Release Date: =
13/11/2007
21:22
=20

-------------------------------------------------------------------------=

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/ =
_______________________________________________
nant-developers mailing list
nan...@li...
https://lists.sourceforge.net/lists/listinfo/nant-developers

No virus found in this incoming message.
Checked by AVG Free Edition.=20
Version: 7.5.503 / Virus Database: 269.15.32/1131 - Release Date: =
14/11/2007 16:54
=20

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.503 / Virus Database: 269.15.32/1131 - Release Date: =
14/11/2007 16:54
=20