You could go with the: set FailedTask=NAnt
idea and simply extend it for multiple failed tasks! set FailedTask="NAnt, otherTask1, otherTask2" Failing that, there is always the stuff I suggested here: http://groups.google.co.uk/group/ccnet-user/browse_thread/thread/369e8bbf50a5c37d# Regards, Shaun On 22 Jan, 19:38, Ruben Willems <[email protected]> wrote: > Hi > > release 1.4.3 is near, and a feature freeze is asked, > so adding some logic for this is not possible for the next release, sorry. > > I'll try to take a look at this again, when the build is out. > > with kind regards > Ruben Willems > > On Thu, Jan 22, 2009 at 8:10 PM, Randy <[email protected]> wrote: > > > Gents, > > > Here's what I was trying to do. In my project configuration file, in > > addition to the actual msbuild call, I run various housekeeping > > scripts, tests and the like. We have two lava lamps that are > > triggered by passing parameters to an executable in the publishers > > section. Two of the parameters are literals that I set when I > > configure it, and the other is the CCNetIntegrationStatus environment > > variable. There was a request for a third light, because now, we only > > want the red light on if the msbuild task itself fails. All other > > failures (tests, other script calls) will trigger the the third > > light. This will provide a visual so the red light will only come on > > when there are compilation errors as opposed to other types of > > breakage. So, my first thought was to initialize a boolean type > > environment variable, say isBuild. I would set this to true prior to > > the msbuild execution and then set it to false after the MSBuild > > execution. If the msbuild task failed, isBuild's value would be true > > so I would pass that value as a fourth parameter to the > > buildnotification executable and evaluate it at the listener to > > determine which light to turn on. > > > However, once I tried to play with variables, I found that this was > > not possible. It would be handy to be able to do something like this, > > but if you had the name of the task the integration failed on, that, > > in combination with the CCNetIntegrationStatus environment variable > > would be enough to work with. Maybe it would be set to null or > > something if the integration succeeds. > > > Also, you are correct, we do run msbuild twice for each project, once > > to run tests in release mode and once in debug as well. > > > On Jan 22, 6:05 am, Ruben Willems <[email protected]> wrote: > > > 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 -- Hide quoted text - > > > > - Show quoted text -
