Icon

You are viewing the documentation of TeamCity 10.x and 2017.x, which is not the most recently released version of TeamCity.
View this page in the latest documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.

 

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The predefined build parameters can originate from several scopes:

  • #Server Build Properties - the parameters generated by TeamCity on the server-side in the scope of a particular build. An example of such property is a build number.
  • #Agent Properties - the parameters provided by an agent on connection to the server. The parameters are not specific to any build and characterize the agent environment (for example, the path to .Net framework). These are mainly used in agent requirements.
  • #Agent Build Properties - the parameters provided on the agent side in the scope of a particular build right before the build start. For example, a path to a file with a list of changed files.

...

There is also a special kind of server-side build parameters that can be used in references while defining other parameters, but which are not passed into the build. See Configuration Parameters below for the list of such properties.

...

  • <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.
Note

When using build parameters of type "Password", referencing them from a dependency such as %dep.<btID>.password_parameter% will not retrieve the actual value. This is done for security reasons to prevent dependencies from accessing the value, thus restricting the possibility of unauthorized access to it.

 

Overriding Dependencies Properties

Since TeamCity 9.0, there is a possibility It is possible to redefine the build parameters in the dependency ( snapshot-dependency ) builds when the current build starts. For example, build configuration A depends on B and B depends on C; when triggering A has , there is the ability to change parameters in any of its dependencies using the following format:

Code Block
reverse.dep.<btID>.<property name>

(warning) Note that if a parameter is redefined in B, but only A is triggered, no parameters change occurs. 

It is also possible to change parameter in all dependencies at once using the syntax:

Code Block
reverse.dep.*.<property name>

...

  • <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.

...

Agent-specific properties are defined on each build agent and vary depending on its environment. Aside from standard properties (for example, teamcity.agent.jvm.os.name or teamcity.agent.jvm.os.arch, etc. — these are provided by the JVM running on agent) agents also have properties based on installed applications. TeamCity automatically detects a number of applications including the presence of .NET Framework, Visual Studio and adds the corresponding system properties and environment variables. A complete list of predefined agent-specific properties is provided in the table below.

If additional applications/libraries are available in the environment, the administrator can manually define the property in the <agent home>/conf/buildAgent.properties file. These properties can be used for setting various build configuration options, for defining build configuration requirements (for example, existence or absence of some property) and inside build scripts. For more information on how to reference these properties, see the Defining and Using Build Parameters in Build Configuration page.

...

Predefined Property

Description

teamcity.agent.name

The name of the agent as specified in the buildAgent.properties agent configuration file. Can be used to set a requirement of build configuration to run (or not run) on particular build agent.

teamcity.agent.work.dir

The path of Agent Work Directory.

teamcity.agent.work.dir.freeSpaceMb Free space available in the  Agent Work Directory.

teamcity.agent.home.dir

The path of Agent Home Directory.

teamcity.agent.tools.dirThe path to the Tools directory on the Agent

teamcity.agent.jvm.os.version

The corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.user.country

The corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.user.home

The corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.user.timezone

The corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.user.name

The corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.user.language

The corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.user.variant

TThe corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.file.encoding

The corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.file.separator

The corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.path.separator

The corresponding JVM property (see JDK help for properties description)

teamcity.agent.jvm.specificationThe corresponding JVM property (see JDK help for properties description)
teamcity.agent.jvm.version The corresponding JVM property (see JDK help for properties description)
teamcity.agent.jvm.java.homeSee the section below for details
teamcity.agent.os.arch.bitsSince TeamCity 10.0 The agent's OS bitness

DotNetFramework<version>[_x86|_x64]

This property is defined if the corresponding version(s) of .NET Framework runtime is installed. (Supported versions are 1.1, 2.0, 3.5, 4.0 - 4.6.1)

DotNetFramework<version>[_x86|_x64]_Path

This property value is set to the corresponding framework runtime version(s) path(s)

DotNetFrameworkSDK<version>[_x86|_x64]

This property is defined if the corresponding version(s) of .NET Framework SDK is installed. (Supported versions are 1.1, 2.0)

DotNetFrameworkSDK<version>[_x86|_x64]_Path

This property value is the path of the corresponding framework SDK version.

DotNetFrameworkTargetingPack<version>_Path

This property value is the path to the corresponding Reference assemblies (AKA Targeting Pack) location. (Supported versions are 2.0 - 4.6.1)

WindowsSDK<version>

This property is defined if the corresponding version of Windows SDK is installed. (Supported versions are 6.0, 6.0A, 7.0, 7.0A, 7.1, 8.0, 8.0A, 8.1, 8.1A, 10)

WindowsSDK<version>_PathThis property value is the path of the corresponding version of Windows SDK.

VS[2003|2005|2008|2010|2012|2013|2015|2017]

This property is defined if the corresponding version(s) of Visual Studio is installed

VS[2003|2005|2008|2010|2012|2013|2015|2017]_Path

This property value is the path to the directory that contains devenv.exe

teamcity.dotnet.nunitlauncher<version>

This property value is the path to the directory that contains the standalone NUnit test launcher, NUnitLauncher.exe. The version number refers to the version of .NET Framework under which the test will run. The version equals the version of .NET Framework and can have a value of 1.1, 2.0, or 2.0vsts.

teamcity.dotnet.nunitlauncher.msbuild.task

The property value is the path to the directory that contains the MSBuild task dll providing the NUnit task for MSBuild, Visual Studio (sln).

teamcity.dotnet.msbuild.extensions2.0

The property value is the path to the directory that contains MSBuild 2.0 listener and tasks assemblies.

teamcity.dotnet.msbuild.extensions4.0

The property value is the path to the directory that contains MSBuild 4.0 listener and tasks assemblies.

teamcity.agent.ownPortThe agent port used by the TeamCity server to connect to the agent
teamcity.agent.protocolThe protocol used for data transfers between the agent and the server
teamcity.agent.cpuBenchmarkCPU benchmarking result for the agent
teamcity.agent.hardware.cpuCountThe number of processors in the build agent system
teamcity.agent.hostnameThe name of the build agent host

...

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.

Note

The environment variables are defined only if they are not already present in the environment: if a started agent already has the Java-related environment variables set, they are not redefined.

...

  • If defined, a custom directory on the agent is searched for Java installations. Defining a custom directory to search for Java is described below.
  • The agent tools directory, <Agent Home Directory>/tools, is checked for containing a jre or jdk. By default, the subdirectories of /tools are not scanned. To search the subdirectories, define teamcity.agent.java.search.path=%agent.tools.NAME%/INNER_PATH in the buildAgent.properties file.
    (warning) For Unix and Mac OS, remember to set the executable bit on the files for TeamCity to be able to launch the discovered Java. 
  • It is checked whether the JAVA_HOME, JDK_HOME, JRE_HOME variables are defined
  • The OS-specific locations, listen in the next section, are checked
  • The PATH environment variables are searched and the discovered directories are checked for containing Java

...

The JDK variables are defined when the JDK is found, the JRE variables are defined when the JRE is found but the JDK is not found.
The _x64 variables point to 64-bit java only; the variables without the _x64 suffix may points point to both 32-bit or 64-bit installations but 32-bit ones are preferred.
If several installations with the same major version and the same bitness but different minor version/update are found, the latest one is selected.

...