...
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 |
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> |
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 |
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.dir | The 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.specification | The 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.home | See the section below for details |
| teamcity.agent.os.arch.bits | Since 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>_Path | This 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 |
teamcity.dotnet.nunitlauncher<version> | This property value is the path to the directory that contains the standalone NUnit test launcher, |
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.ownPort | The agent port used by the TeamCity server to connect to the agent |
| teamcity.agent.protocol | The protocol used for data transfers between the agent and the server |
| teamcity.agent.cpuBenchmark | CPU benchmarking result for the agent |
| teamcity.agent.hardware.cpuCount | The number of processors in the build agent system |
| teamcity.agent.hostname | The 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/toolsare not scanned. To search the subdirectories, defineteamcity.agent.java.search.path=%agent.tools.NAME%/INNER_PATHin thebuildAgent.propertiesfile. 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_HOMEvariables are defined - The OS-specific locations, listen in the next section, are checked
- The
PATHenvironment 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.
...