Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Before reading this page, it is highly recommended you read the Variables, Objects & Expressions page.

Variables

Variables store dynamic values which can be used during the build process. A full description and further conceptual information can be found on the Variables, Objects & Expressions concept page.

This page discusses information regarding the hands-on use of variables.

Variable Types

Each variable must be assigned a type which limits what time of information can be stored in a variable. Note that all variable types, except expression variables, can have their values changed during the build process.

Variables can be one of the following types:

Expression

Expression variables store an expression that will be evaluated every time the variable is used. For example, you could assign an expression variable the value '$Server.Now$' which will translate to the current server time every time it is called.

Text

Text variables store any values as plain text. Regardless of the values that are entered into a text variable, the value will always be returned as a plain string.

Numeric

Numeric variables can only contain numbers.

Date Time

DateTime variables can only contain full datetime values. These values are always converted to UTC time when the value is saved.

Date

Date variables can only contain date values. Note that these values are stored as is, and they are not converted to UTC time.

Time

Time variables can only contain time values. Note that these values are stored as is, and they are not converted to UTC time.

Password

Password variables store passwords that are hidden from the user at every opportunity within Continua. Note that password variables should only be used in password fields for actions so that their value can be masked correctly. If they are used in a standard text field, their value will be displayed in the build log.

Variable Prompt Types

All configuration variables can be assigned a prompt type which enables users to set a variable's value when queuing a manual build.

Configuration Variables can be given the following prompt types:

  • Text
  • Memo
  • Password
  • Numeric
  • Date Time
  • Time Span
  • Date
  • Time
  • Selection
  • Multiple Selection
  • Boolean

Read the Variable Prompt Types page for more information on these prompt types.

Variable Namespaces

Build Variables

 

Configuration Variables

 

Project Variables

 

Application Variables

 

Environment Variables

 

Creating and Editing Variables

 

 

Configuration variables have an extra option when creating them, Prompt Type. If a prompt type is set, you will be required to supply a value for that variable when you manually start a build. The prompt type supplied determines the input field in which you supply the value.

 

Example 1 - Text Type/Boolean Prompt Type

In this example, I've created a variable called MakePackages and set it to a Boolean prompt type.

For demonstration purposes, the mock Configuration this variable belongs to has two stages. Stage 1 builds my project and out puts a bunch of file. Stage 2 takes the output of Stage 1 and generates an installer (a.k.a makes the packages). I don't want to make the packages every time I execute the configuration though so I've setup the configuration to only execute stage 2 when the MakePackages configuration variable is set to true. By making this a prompt type variable, I will be able to supply the value of this variable whenever I manually start a build. When I manually start a build, I will see the following dialog.

Under the Variables heading, you can see the MakePackages variable in a checkbox format. When you create a Boolean prompt type variable, it gets rendered as a checkbox because the value can either be true (checked) or false (unchecked). Now when you manually queue the configuration, you can set the value of the variable by checking or unchecking the checkbox.

 

Example 2 - Text Type/Selection Prompt Type

In this example, I've created a variable called TagBuildAs and set it to a Selection prompt type. This type of prompt type will display a text field in which you supply all the possible values for this variable. The value you supply in the Value field must be in the list of values you supply in the Options field.

For demonstration purposes, the mock Configuration this variable belongs to has a Tag Build action which contains the value %TagBuildAs% as one of its values. This means the build will be tagged with whatever value the variable TagBuildAs contains. By making TagBuildAs a selection prompt type variable, the user can select which value to use when manually starting a build. If you were to manually start a build, you would see the following dialog.

Now when you start a build you can specify the value from the drop down list.

 

Example 3 - Text Type/Multiple selection Prompt Type

In this example, I've created a variable called AgentsToRunOn and set it to a Multiple selection prompt type. This type of prompt type will display a text field in which you supply all the possible values for this variable. The value you supply in the Value field must be in the list of values you supply in the Options field.

As a result of this prompt type variable, you will now see each agent name with a checkbox next to it when you manually start a build.

For demonstration purposes, the mock Configuration this variable belongs to has a check before each stage (using Agent Requirements in Stage Options) that checks to see if the Agent's hostname is in the list of options you selected when the build was manually started. Here's an example of what a stage might look like with this kind of agent requirement.

At build time, %AgentsToRunOn% will contain every value you ticked on the queue dialog, in other words, every agent host name you specified. By selecting the Contains operator then specifying the expression $Agent.Hostname$, you're basically saying "Only run this stage when the list of agents I selected on the queue dialog contains the name of any agent registered with Continua".

Note: When explicitly forcing a stage to run on an agent, you bypass all the advantages of agent compatibility. If the agent you forced a stage to run on is unable to execute the stage then the build will sit on the queue waiting for a compatible agent whose name is the one you explicitly told the stage to run on. It will not under any circumstance pick an agent that's compatible whose name doesn't match the one or ones you specified.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • No labels