Ivan,
I haven't had time to read through your length email yet, but I still want
to share some information with you ...
NAnt already has support for executing a specific target when the build
fails by creating a property named "nant.onfailure" with a value
corresponding with the name of the target that should be executed.
If you want to send an email on build success or failure, you can use the
NAnt.Core.MailLogger :
NAnt.exe -buildfile:.... -logger:NAnt.Core.MailLogger
you need to configure the MailLogger using a predefined set of properties in
your buildfile (see the NAnt SDK docs for more information) :
<property name="MailLogger.mailhost" value="mail.dunnowhat.com" />
<property name="MailLogger.from" [EMAIL PROTECTED] />
<property name="MailLogger.failure.notify" value="true" />
<property name="MailLogger.success.notify" value="true" />
<property name="MailLogger.failure.to" value="[EMAIL PROTECTED]" />
<property name="MailLogger.success.to" value="[EMAIL PROTECTED]" />
<property name="MailLogger.failure.subject" value="build failure" />
<property name="MailLogger.success.subject" value="build success" />
This will result in a single email for the results of all nested builds.
Gert
----- Original Message -----
From: "Ivan Tarasov" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 08, 2003 7:01 PM
Subject: [nant-dev] onFail patch
> Hello nant-developers,
>
> I want to discuss some ideas I have on failures which occur during the
> build process. I've been desperately trying to solve the problems
> which I'm going to address in this letter using the standard features
> of NAnt and I've found that the ways by which I can solve these
> problems are very far from being nice and reasonable.
>
> Consider such a problem (it is a simplified version of a problem I
> had):
> I have a build file for quite a big project, which consists of several
> subprojects. For simplicity, lets consider that these subprojects are
> independent and built in some fixed order. To be more general, I have
> a bunch of targets, which i call using the <call> task:
>
> <target name="A" />
> <target name="B" />
> <target name="C" />
> ...
> <target name="build">
> <call target="A" />
> <call target="B" />
> <call target="C" />
> ...
> <call target="send.mail.on.successful.build" />
> </target>
>
> The problem is, that I only get mail on successful build. And the
> bigger problem is, that when some of the A,B,C targets fails and I
> don't get any mail, I don't know, which target has the problem (of
> course, unless I do take a look at the log). To be more specific, I
> also want that different mail messages were sent to the different mail
> addresses in case of different targets failures (sorry for a bit
> awkward explanation).
>
> Of course, in <call> I can add failonerror="false", and then after
> each call check some property which is set in the end of the
> previously called target, but it is a really ugly hack!
> I'm still not sure, if it was the only way of doing failure
> notification, but it was the only one I could guess.
>
> I've had some time thinking this over, and came to a conclusion that
> some kind of "exception handling" similar to the C# kind is needed.
> I've inspected the .Core source code (thanks for the great code, it's
> very easy to read it!), and decided to make a small patch.
>
> My idea of solution of the problem was the following:
> we add the onfail attribute to <task> (I mean the base class here) and
> <target>, and, in case of failure, the target which has the name of the
> value of the onfail attribute is called. Surely enough, I don't want
> only to send the mail in case of unsuccessful build, I had some other
> things to do :-)
>
> There are some tricky parts in such a solution:
> - how do we handle the failure of the task, which was called "onfail"
> - getting the failure info in the "onfail" task (for example, to send
> part of the build log to the "subscribed" developers)
> - probably, some other I don't remember now...
>
> The first one is "solved", but I don't like the way I did it: I've
> created host for multiple exceptions, so the data of all can be
> retrived. I wanted to bind the exceptions by adding the exception from
> failed task/target as a constructor parameter for the second
> exception, but it is impossible, because target (in the meaning of
> class) does not know, that it was called "by reason of the exception".
>
> I have some thoughts on the second one (it is not solved in any way),
> but it can demand quite a serious design ideas/changes. Again, I don't
> have the stories, which describe how I want to see such a feature.
> Still I'm sure it can be very useful and needs lots of opinions to
> base on.
>
> I've implemented the tests first, the do pass and are included into
> the patch. The patch is in the attach, but it is in quite a strange
> format (I've ripped the parts of the changes history from Perforce).
> Sorry for this inconvinience. Also the new file (with the strange
> exception implementation) is in the attach.
>
> I'm ready to discuss any ideas of what was done wrong and how it
> should be done. I'm ready to take part in the development of this
> feature if it will be redesigned.
>
> --
> Best regards,
> Ivan mailto:[EMAIL PROTECTED]
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
