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 -
