In the 1.5.0 release we added the ability to define dynamic build parameters. A dynamic build parameter is a value that can change for different builds – and it can be set by the user when they perform a force build.

This addresses a simple issue in the current CruiseControl.NET – if even one parameter in a project needs to differ between builds, multiple projects are needed! Now, an administrator can define just one project and allow multiple different variations on it.
At the bottom of this page are wiki links to examples.

The following parameters are defined:

As well as custom parameters, a number of parameters are defined by the system. These are the same as the Integration Properties. To use one of these parameters, prefix it with a $, e.g. $CCNetBuildCondition.

Using Parameters

Parameters can be used for tasks/publishers, source control blocks and labellers.

Using parameters can be done in one of two ways: configuration definition or implied replacement. {warning}
Not all items allow the use of dynamic parameters. To be able to use the parameters a task must expose a dynamicValues element. {warning} {note}
With CruiseControl.NET 1.5 dynamic values are constants. These are initialised at the start of a build and cannot be changed for that build. They provide a mechanism for getting values from an external source, not a mechanism for storing values internally. {note}

Configuration Definition

In this approach the parameter usage is defined within the configuration file. This is generally the more complex approach, but it provides better control over how the parameters are applied.

To us this approach a Dynamic Values element must be added to the task/publisher:

2  <directValue>
3    <property>buildArgs</property>
4    <parameter>BuildArgs</parameter>
5    <default>-t:Dev</default>
6  </directValue>

The following dynamic values are defined:

Implied Replacement

In this approach the parameters are defined inline in the properties. When the configuration is loaded, CruiseControl.NET reads these parameters and converts them into dynamicValues (as above).

An inline definition is contained with a $\[...\] block and can consist of one or more parts seperated by pipe characters. The first part is the parameter name, the second part is the default value and the third part is the format (only used when a replacementValue is generated).

If an integration property is being used, this will need to have both the $ sign for the implied replacement, plus for the integration property, e.g. $\[$CCNetUser\].

Some examples are:
  • <buildArgs> $\[BuildArgs\] </buildArgs> - use the BuildArgs parameter as a direct replacement, if omitted then the value will be empty.
  • <buildArgs> $\[BuildArgs\|-t:Dev\] </buildArgs> - use the BuildArgs parameter as a direct replacement, if omitted then the value will be "-t:Dev".
  • <buildArgs>-t: $\[BuildType\|Dev\] -ll: $\[LogLevel|50|00\] </buildArgs> - a replacementValue will be generated using the two parameters - the second parameter will use the "00" format.
  • <buildArgs>-t: $\[$CCNetBuildCondition\] -ll: $\[LogLevel|50|00\] </buildArgs> - a replacementValue will be generated that uses the system parameter of CCNetBuildCondition and a custom parameter called LogLevel.

Full examples