I too would find variable manipulation to be handy. I'm in the process if finding a work-around now.
Randy On Jan 20, 3:27 am, Ruben Willems <[email protected]> wrote: > Hi > > now I understand it better, but on how to implement it, > I have to think it over ;-) > do not have a solution in mind right away. > > with kind regards > Ruben Willems > > On Tue, Jan 20, 2009 at 9:23 AM, CinnamonDonkey < > > > > [email protected]> wrote: > > > Hi Ruben, > > > You are right... there are a lot of Cruise Control specific variables > > already exposed and they are very handy too :-). I'm using at least > > half of them in my scripts ;-) > > > I was just thinking that form a USER data point of view, it would be > > nice to have a mechanisim by which the user could hold the odd bit of > > data in one place along with all the other state information. The > > alternative is to hand craft more complex scripts and to have them > > create yet more files and access/update these files on every run. > > > One potential issue with this method is that the data being held could > > become out of sync. Lets say there are 3 build tasks (I actually have > > 5 in a full build run) task 1 runs and updates the file, task 2 runs > > and fails (or worse, locks and gets terminated), task three never gets > > to run. The users variable file is now out of sync holding data that > > could corrupt the next build (depending on what the build process is > > and what the data represents). > > > Cruise Control can be thought of as being Atomic, in that, it knows > > when the build has started and it knows for sure when it has finished. > > It could create a enviroment variable on behalf of the usere at the > > start of the build process representing the project user state data, > > held in the .state file and then at the end of the process write the > > value left in the enviroment variable back to the state file so that > > it may persist between builds. > > > Addition options could be available to specify clean up of the > > variable on a failed build say, or a default value should the variable > > not yet exist (perhaps because the .state file does not yet exist). > > > It's just a thought, > > Shaun > > > On 19 Jan, 15:34, Ruben Willems <[email protected]> wrote: > > > Hi > > > > there are already a lot of data exposed to the calling executables > > > these are the integration properties. > >http://confluence.public.thoughtworks.org/display/CCNET/Integration+P... > > > > for example the exec task gets these via environment variables, > > > Nant and msbuild gets these as propertieshttp:// > > confluence.public.thoughtworks.org/display/CCNET/NAnt+Taskhttp://confluence.public.thoughtworks.org/display/CCNET/MsBuild+Task > > > > with kind regards > > > Ruben Willems > > > > On Mon, Jan 19, 2009 at 4:25 PM, CinnamonDonkey < > > > > [email protected]> wrote: > > > > > Hi All, > > > > > I was wondering, is it possible to include user defined state > > > > variables in the .state file? > > > > > If not, this would be a handy feature. The ability to define a State > > > > Variable in the Project block which is loaded as an enviroment > > > > variable and therefore accessable/modifyable by external applications. > > > > The enviroment variable could be initialised from the .state file at > > > > the start of a build and then written back to the .state file at the > > > > end of a build. > > > > > What do people think? > > > > > Cheers, > > > > Shaun- Hide quoted text - > > - Show quoted text -
