> Below is a log snippet from when I issued an Abort Build to when it
> aborted.

> I was expecting the project to remain in its previous 'successful'
> state (akin to killing the ccnet.exe console), but instead the project
> flipped to a failure state and ended up emailing the engineers on the
> last modification list with no errors listed or any indication of the
> abort.

> Is this behavior by design, or did it happen to be caused by where the
> the project was (mid-Visual Studio build) when the abort was
> processed?

> Thank you,

> --jdavidi

> 2008-08-29 08:21:50,739 [5532:INFO] jdav aborted the running Build for
> project: CruiseControl 9.04 Base RateBill
> 2008-08-29 08:21:51,320 [CruiseControl 9.04 Base RateBill:DEBUG]
> 2008-08-29 08:21:51,330 [CruiseControl 9.04 Base RateBill:DEBUG]
> Microsoft (R) Visual Studio Version 8.0.50727.762.
> 2008-08-29 08:21:51,330 [CruiseControl 9.04 Base RateBill:DEBUG]
> Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
> 2008-08-29 08:21:51,330 [CruiseControl 9.04 Base RateBill:DEBUG]
> ------ Rebuild All started: Project: DBLibrary, Configuration: Debug
> Win32 ------
> 2008-08-29 08:21:51,330 [CruiseControl 9.04 Base RateBill:DEBUG]
> Deleting intermediate and output files for project 'DBLibrary',
> configuration 'Debug|Win32'
> 2008-08-29 08:21:53,212 [5532:INFO]
> ------------------------------------------------------------------
> 2008-08-29 08:21:53,212 [5532:INFO] ---------The Build Process was
> successfully aborted---------------
> 2008-08-29 08:21:53,212 [5532:INFO]
> ------------------------------------------------------------------
> 2008-08-29 08:21:53,232 [CruiseControl 9.04 Base RateBill:INFO] Task
> execution failed
> 2008-08-29 08:21:53,232 [CruiseControl 9.04 Base RateBill:INFO] Task
> output:
> Microsoft (R) Visual Studio Version 8.0.50727.762.
> Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
> ------ Rebuild All started: Project: DBLibrary, Configuration: Debug
> Win32 ------
> Deleting intermediate and output files for project 'DBLibrary',
> configuration 'Debug|Win32'

> 2008-08-29 08:21:53,232 [CruiseControl 9.04 Base RateBill:INFO] Devenv
> build complete.  Status: Failure
> 2008-08-29 08:21:53,453 [CruiseControl 9.04 Base RateBill:INFO]
> Emailing "CruiseControl 9.04 Base RateBill Build Failed" to
> x...@yyy.com, x...@yyy.com
> 2008-08-29 08:21:53,573 [CruiseControl 9.04 Base RateBill:INFO]
> Integration complete: Failure - 8/29/2008 8:21:53 AM
> 2008-08-29 08:21:53,683 [CruiseControl 9.04 Base RateBill:INFO]
> Integrator for project: CruiseControl 9.04 Base RateBill is now
> stopped.

> I was expecting the project to remain in its previous 'successful'
> state (akin to killing the ccnet.exe console), but instead the project
> flipped to a failure state and ended up emailing the engineers on the
> last modification list with no errors listed or any indication of the
> abort.

> Is this behavior by design, or did it happen to be caused by where the
> the project was (mid-Visual Studio build) when the abort was
> processed?

> Ross

>> 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

> 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

> 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