Hello Randy and Shaun To help come up with a reasonable solution, it is always good to know how people are using features. What kind of data are you passing in the variables?
Version numbers, paths, task results, something else? Dave Cameron CruiseControl.NET - http://ccnet.thoughtworks.com On Wed, Jan 21, 2009 at 2:28 AM, Randy <[email protected]> wrote: > > 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 -
