On 04/09/2008, at 9:09 PM, Daniel Hommel <[EMAIL PROTECTED] 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

Reply via email to