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 >
