Predefined Build Parameters

Dependencies Properties

These are properties provided by the builds the current build depends on (via a snapshot or an artifact dependency).

In the dependent build, dependencies properties have the following format:

• <btID> – is the ID of the build configuration to get the property from. Only the configurations the current one has snapshot or artifact dependencies on are supported. Indirect dependencies configurations are also available (e.g. A depends on B and B depends on C - A will have C's properties available).

• <property name> – the name of the build parameter of the build configuration with the given ID.

Overriding Dependencies Properties

It is possible to redefine the build parameters in the snapshot-dependency builds when the current build starts. For example, build configuration A depends on B and B depends on C; on triggering, A can change any parameter used in B or C with the following property:

To change a parameter in all dependencies at once, use a wildcard:

Thus, each dependent build in a chain can redefine parameters in any of its dependency builds.

If build configurations A and B are trying to set different values for the same parameter in the build configuration C, the following rules apply:

• if A depends on B by a snapshot dependency either directly or transitively, the value proposed by A will be used in C (and vice versa, if B depends on A)

• if both A and B do not depend on each other, TeamCity will consider it a conflict and will not modify the original value in C. Instead, two other parameters will be created for C:
  • conflict.<btA>.<property name>=<valueA>
  • conflict.<btB>.<property name>=<valueB>

The reverse.dep.* parameters are processed on queuing of the build where the parameters are defined. As the parameters' values should be known at that stage, they can only be defined either as build configuration parameters or in the custom build dialog. Setting the parameter during the build has no effect.

Pushing a new parameter into the build will supersede the "Do not run new build if there is a suitable one" snapshot dependency option and may trigger a new build if the parameter is set to a non-default value.

Note that the values of the reverse.dep. parameters are pushed to the dependency builds "as is", without reference resolution. %-references, if any, will be resolved in the context of the build where the parameters are pushed to.
<property name> is the name of the property to set in the noted build configuration. To set system property, <property name> should contain the system. prefix.

VCS Properties

These are the settings of VCS roots attached to the build configuration.

VCS properties have the following format:

• <VCS root ID> – is the VCS root ID as described on the Configuring VCS Roots page.

• <VCS root property name> – the name of the VCS root property. This is VCS-specific and depends on the VCS support. You can get the available list of properties as described above. If there is only one VCS root in a build configuration, the <VCS root ID>. part can be omitted.

Properties marked by the VCS support as secure (for example, passwords) are not available as reference properties.

Branch-Related Parameters

When TeamCity starts a build in a build configuration where a branch specification is configured, it adds a branch label to each build. This logical branch name is also available as a configuration parameter:

To distinguish builds started on a default and a non-default branch, there is an additional boolean configuration parameter available since 7.1.5 which allows differentiating these cases:

For Git & Mercurial, TeamCity provides additional parameters with the names of VCS branches known at the moment of the build start. Note that these may differ from the logical branch name as per branch specification configured. This VCS branch is available from a configuration parameter with the following name:

Where <VCS root ID> is the VCS root ID as described on the Configuring VCS Roots page.

Other Parameters

Java Home Directories

When a build agent starts, first the installed JDK and JRE are detected; when they are found, the Java-related environment variables are defined as described in the section below.