It would always be something that can be resolved to a string or
number (probably more commonly a number).
Examples:
LAST_DEFECT_COUNT = 2056
LAST_LOC_COUNT = 8456
LAST_PARSED_FILE = "ParseMe1234.txt"
I would imagine the end user creating parameters in a state control
block:
<stateControl>
<userVar name="LAST_DEFECT_COUNT" type="Number" defaultValue=0 /
>
<userVar name="LAST_LOC_COUNT" type="Number" defaultValue=0 />
<userVar name="LAST_PARSED_FILE" type="String" defaultValue=""
onBuildFailed="" />
</stateControl>
When a project build triggers it loads these variables from the .state
file and creates enviroment variables containing the value stored
there; should a variable not exist in the .state file it will be
initialised to the defaultValue or some sensible value.
NOTE: The enviroment variable name will be CCNET_<userVar>, this is to
avoid silly things being done like:
<stateControl>
<userVar name="PATH" type="String" />
</stateControl>
The enviroment variable is available for read/write by the user
tasks.
The build runs as normal, at the end of the build process -
Build Success: The value of the user defeined enviorment variables
are written back to the .state file ready for the next build.
Build Failed: If onBuildFailed is defined set the enviroment
variable to the value in onBuildFailed and write it back to the .state
file, other wise just write back what is in the variable.
I hope this helps :)
Shaun
On 22 Jan, 10:46, David Cameron <[email protected]> wrote:
> 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 -
