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 -
