Hi
this sounds like issue 541 (unresolved) http://jira.public.thoughtworks.org/browse/CCNET-514 in the current trunc, every task as a description field (not mandatory) so if it's only for pointing out which task failed this field can be used. and this will solve 514 also ;-) but it will not be user configurable, which is what Randy asked for in the beginning --> set some variables, and keep their value through the build with kind regards Ruben Willems On Thu, Jan 22, 2009 at 11:57 AM, David Cameron <[email protected]> wrote: > > 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 - >
