Randy,

This sounds like a good idea. It sounded so good I thought we had
something similar already and just spent some time searching the docs
for one. I guess we do not.

How do you think it should work? Maybe a variable with the name of the
task that failed?

set FailedTask=NAnt

... but then if there is more than one NAnt task.

Dave Cameron
CruiseControl.NET - http://ccnet.thoughtworks.com

On Wed, Jan 21, 2009 at 3:03 AM, Randy <[email protected]> wrote:
>
> Thanks for your response David.  The environment variables you
> mentioned seem to exist at the project level.  I'm looking to try to
> set something at the task level.  For example, after a build, we may
> run some tests and based on the results of the test, post the binaries
> back to source control.  I was looking for a way to set a boolean type
> variable, say isBuild, to true before the actual build task and false
> afterwards so we would be able to discern whether the failure was at
> the build task, or whether it failed at another point, such as the
> test task or a copy task.  I then wanted to pass this value to a post-
> build program that we run in the publishers section to control some
> information radiators we're using.
>
> On Jan 17, 9:10 am, "David Cameron" <[email protected]> wrote:
>> Hi Randy
>>
>> I'm not sure what you mean by "whether the task running was an actual
>> software build"? Depending on what you are trying to determine, some
>> of the environment variables that CCNet sets might be of use. They are
>> listed on the confluence page for the <exec> 
>> task:http://confluence.public.thoughtworks.org/display/CCNET/Executable+Task
>>
>> For example CCNetBuildCondition could allow you to distinguish between
>> builds that were forced and those that were triggered by someone
>> checking in to the sourcecontrol for the project. Is that the sort of
>> thing you are trying to distinguish?
>>
>> Dave
>>
>>
>>
>> On Wed, Jan 14, 2009 at 5:44 AM, Randy <[email protected]> wrote:
>>
>> > Can anybody see a downside to adding a field to the .state file?  I
>> > was trying to set a boolean environment variable (isBuild = {y,n})
>> > from within the build based on whether the task running was an actual
>> > software build or not.  That didn't work out too well since
>> > environment variables can't be changed from within the environment.
>> > My next thought was to write this status indicator to a file and since
>> > the state file is already being maintaned for each build, it seemed
>> > like a good idea to just add another field.
>>
>> > However, I don't know what the ramifications would be (would it cause
>> > a problem with some other part of cruisecontrol.net).
>>
>> > Any thoughts (or any other ideas on how to handle this).
>>
>> > Also, if the state file is deleted, at what point during the build is
>> > it recreated?
>>
>> > Thank you,
>>
>> > Randy Neidigh- Hide quoted text -
>>
>> - Show quoted text -

Reply via email to