> On 04/09/2008, at 9:09 PM, Daniel Hommel <daniel.hom...@it-designers.de>
> wrote:

>> Daniel Hommel writes:
>>> Ross Patterson writes:
>>>> I wouldn't go so far as to say it's by design, but it certainly is the
>>>> way CCNet works.  The build has already started and must have a final
>>>> status, and builds either succeed or fail - there is no in-between
>>>> state.  I'll grant that the abort code should include an error to the
>>>> effect that the build failed because it was aborted, rather than just
>>>> being quiet.

>>>> Ross

>>> While investigating on this i found out that it seems to be the easiest
>>> way to fix the mentioned behavior to pull the RunnableProcess class out
>>> of the ProcessExecutor class and also use it in the ProcessMonitor
>>> instead of using the Process class directly. If that's not a problem i
>>> think i can provide a patch.

>>> regards,

>>> Daniel

>> I tried to insert an error message in the standard error output of the
>> executable which is passed to the ProcessResult class. It is working for
>> the executable task and the nant task since they don't use a logger like
>> the msbuild task does and both use the same XML format (seems like
>> msbuild is the only task that doesn't).

>> With the msbuild task i see two options. The first option would be to
>> merge the output of the logger AND the ProcessResult transformed into
>> XML. A drawback is that you see each error or warning 2 times in the
>> build report page (could be fixed). The second option would be to
>> somehow insert the error message in the XML file that the logger writes
>> before merging it.

>> A different and maybe the best approach would be to not insert the error
>> message in the ProcessResult and just throw an exception with a
>> meaningful message like the one that gets thrown when a timeout occurs.

>> Which way to go? I guess i'd prefer throwing an exception.

>> regards,

>> Daniel

> Throwing an exception sounds very simple. So I like it for that reason.

> We're using bamboo on my current project and have been killing a lot of
> builds. It has been quite useful to see what happened in the build up
> until the kill. If you use the exception approach will the build log
> show the activity up until that point?

> Dave