...
- Environment variables. These are pulled in from the system automatically and cannot be changed. These environment variables are system wide and include common windows values such as PATH and COMPUTERNAME.
- Application variables. These are the highest variables that the user can define. Any variable defined in the application namespace can be used anywhere in Continua CI.
- Project variables. These variables can be accessed by any configuration or build that belong to that project.
- Configuration variables. These are only accessible from within the configuration and its builds.
- Build variables. These are the lowest level of variables and will override any of the variables listed above.
The values of Application, Project and Configuration variables cannot be modified during a build. Their values will not change over the course of a build. To access these variables using the query syntax (this is explained in greater detail below), you would prefix the variables with their namespace. Eg. %Application.MyVariable%, %Project.MyVariable%, %Configuration.MyVariable%. Alternatively, you can choose to not specify a namespace for a variable. If no namespace is provided then it will try and get the value for that variable by searching the namespaces from the bottom up (see figure 1). Not prefixing your variable with a namespace is the only way to access build namespace variable values. It's also a simple way to allow namespaces to override their parents.
Variable Example
If you have the following:
A project variable called %MyVariable% with a value of 1.
A configuration variable also called %MyVariable% with a value of 2.
These are the results you would get if you referred to these variables:
%MyVariable% would return 2 (as there is no build variable called %MyVariable%, the build pulls the value from the configuration, not the project, as the configuration is further down the hierarchy).
%Configuration.MyVariable% would return 2 (retrieves the configuration variable as it has been specifically called).
%Project.MyVariable% would return 1 (retrieves the project variable as it has been specifically called).
If you ever change the value of a non-build variable during the build process, you are actually creating a new variable in the build namespace. This variable will have the same name and as you are now dealing with a build variable, you will need to refer to it without a namespace prefix for the remainder of the build.
For example, given the %MyVariable% values above:
If you assign the value 3 to %MyVariable%, you will create a new variable called %MyVariable% in the build namespace.
These are the new results you would get referring to %MyVariable%:
%MyVariable% would return 3 (This returns the value of the build variable)
%Configuration.MyVariable% would return 2 (This value never changed)
%Project.MyVariable% would return 1 (This value never changed)Once a build has been triggered it will try to match up a variable name to one
Defining Variables
The method used to declare variables is different depending on the variable level.
...
- Text variables can take standard string and text inputs
- Numeric variables can take any numeric value.
- Expression variables. These can contain references to other variables and objects in Continua CI.
...
...
Objects & Expressions
Throughout Continua you will come across input fields which accept Expressions in their value. Expressions are built up at design time then evaluated at run time. An Expression can reference a Continua Variable or a Continua Object. The UI differentiates these two types by starting and ending an Expression with the "%" character for variables and a "$" character for objects, these two keys will be referred to as "starting keys". A Variable Expression would look something like "%Configuration.MyOwnVariable%" and an Object Expression would look something like "$Build.BuildNumber$". To determine if an input field accepts Expressions as values, press a starting key and wait for the auto-complete drop down to appear below the input field.
...