TeamCity Cloud 2021.1 Help

Setting up and Running Additional Build Agents

Before you can start customizing projects and creating build configurations, you need to add and configure build agents. Review the agent-server communication and Prerequisites sections before proceeding with agent installation. Make sure to also read our security notes on maintaining build agents and licensing policy on adding new agents.

Prerequisites

Necessary OS and environment permissions

Before the installation, review the Conflicting Software section. In case of any issues, make sure no conflicting software is used.

Note that to run a TeamCity build agent, the environment and user account used to run the Agent need to comply with the following requirements:

Common

The agent process (Java) must:

  • be able to open outbound HTTP connections to the server URL configured via the serverUrl property in the buildAgent.properties file (typically the same address you use in the browser to view the TeamCity UI). Sending requests to the paths under the configured URL should not be limited. Ensure that any firewalls installed on the agent, network configuration, and proxies (if any) comply with these requirements.

  • have full permissions (read/write/delete) to the following directories recursively: <agent home> (necessary for automatic agent upgrade and agent tools support), <agent work>, <agent temp>, and agent system directory (set by workDir, tempDir, and systemDir parameters in the buildAgent.properties file).

  • be able to launch processes (to run builds).

  • be able to launch nested processes with the following parent process exit (this is used during agent upgrade).

Windows

  • Log on as a service (to run as Windows service).

  • Start/Stop service (to run as Windows service, necessary for the agent upgrade to work, see also Microsoft KB article).

  • Debug programs (required for take process dump functionality).

  • Reboot the machine (required for agent reboot functionality) .

  • To be able to monitor performance of a build agent run as a Windows service, the user starting the agent must be a member of the Performance Monitor Users group.

Linux

  • The user must be able to run the shutdown command (for the agent machine reboot functionality and the machine shutdown functionality when running in a cloud environment).

  • If you are using systemd, it should not kill the processes on the main process exit (use RemainAfterExit=yes). See also how to set up automatic agent start under Linux.

Build-related Permissions

The build process is launched by a TeamCity agent and thus shares the environment and is executed under the OS user used by the TeamCity agent. Ensure that the TeamCity agent is configured accordingly. See Known Issues for related Windows Service Limitations.

Agent-Server Data Transfers

A TeamCity agent connects to the TeamCity server via the URL configured as the serverUrl agent property. This is called unidirectional agent-to-server connection.

Unidirectional Agent-to-Server Communication

Agents use unidirectional agent-to-server connection via the polling protocol: the agent establishes an HTTP(S) connection to the TeamCity Server, and polls the server periodically for server commands.

Generating Authentication Token

The recommended approach to connecting a self-hosted agent to a TeamCity Cloud instance is to generate a unique authentication token for this agent. To do this, go to Agents, open the Install Build Agents menu in the upper right corner of the screen, and click Use authentication token. There are two options:

  • Generate plain-text token: you need to copy the generated token and enter it in the build agent configuration file. On Windows, you will be prompted to enter it right in the Configure Build Agent Properties installation dialog.

  • Download config: enter an agent name (name attribute in the build agent config) and download the entire config file. Place it as the buildAgent.properties file in the build agent directory.

Please generate own token or configuration file per each self-hosted agent.

Installing Additional Build Agents

  1. Install a build agent using any of the following options:

  1. After installation, configure the agent specifying its name, the address of the TeamCity server, and the authentication token in the conf/buildAgent.properties file.

  2. Start the agent. If the agent does not seem to run correctly, check the agent logs.

Installing via Windows installer

  1. In the TeamCity web UI, navigate to the Agents tab.

  2. Click the Install Build Agents link and select Windows Installer to download the installer.

  3. On the agent, run the agentInstaller.exe Windows Installer and follow the installation instructions.

Installing via Docker Agent Image

  1. In the TeamCity UI, navigate to the Agents tab.

  2. Click the Install Build Agents link and select Docker Agent Image.

  3. Follow the instructions on the opened page.

Installing via ZIP File

  1. Make sure a JDK (JRE) 1.8.0_161 or later (Java 8-11 are supported, but 1.8.0_161+ is recommended) is properly installed on the agent computer.

  2. On the agent computer, make sure the JRE_HOME or JAVA_HOME environment variables are set (pointing to the installed JRE or JDK directory respectively).

  3. In the TeamCity web UI, navigate to the Agents tab.

  4. Click the Install Build Agents link and select one of the two options to download the archive:

    • Minimal ZIP file distribution: a regular build agent with no plugins

    • (since TeamCity 2020.1) Full ZIP file distribution*: a full build agent prepacked with all plugins currently enabled on the server

  5. Extract the downloaded file into the desired directory.

  6. Navigate to the <installation path>\conf directory, locate the file called buildAgent.dist.properties and rename it to buildAgent.properties.

  7. Edit the buildAgent.properties file to specify the TeamCity server URL (HTTPS is recommended, see the notes), the name of the agent, and the authentication token. Refer to the Build Agent Configuration page for details on agent configuration.

  8. Under Linux, you may need to give execution permissions to the bin/agent.sh shell script.

On Windows, you may also want to install the build agent Windows service instead of using the manual agent startup.

Installing via Agent Push

TeamCity provides the Agent Push functionality that allows installing a build agent to a remote host.

Currently, supported combinations of the server host platform and targets for build agents are:

  • from the Unix-based TeamCity server, build agents can be installed to Unix hosts only (via SSH)

Remote Host Requirements

There are several requirements for the remote host:

Platform

Prerequisites

Linux

  • Installed JDK (JRE) 8-11 (1.8.0_161 or later is recommended). The JVM should be reachable via the JAVA_HOME (JRE_HOME) global environment variable or be in the global path (instead of being specified in, for example, user's .bashrc file)

  • The unzip utility.

  • Either wget or curl.

Windows

  • Installed JDK/JRE 8-11 (1.8.0_161 or later is recommended).

  • Sysinternals psexec.exe has to be installed on the TeamCity server and accessible in paths. You can install it on the Administration | Tools page.
    Note that PsExec applies additional requirements to a remote Windows host. Make sure the following preconditions are satisfied:

    • Administrative share on a remote host is enabled and accessible.

    • Remote services work (MMC snap-in can connect to the machine).

    • Remote registry works (regedit can connect to the machine via services.msc).

    • Server and workstation services are running (check via services.msc).

    • Classic network authentication is enabled.

You can test the connection with the following commands:

net use \\target\Admin$ /user:Administrator dir \\target\Admin$

Installation

  1. In the TeamCity Server web UI navigate to the Agents | Agent Push tab, and click Install Agent.
    If you are going to use same settings for several target hosts, you can create a preset with these settings and use it each time when installing an agent to another remote host.

  2. In the Install agent dialog, either select a saved preset or choose "Use custom settings", specify the target host platform, and configure corresponding settings. Agent Push to a Linux system via SSH supports custom ports (the default is 22) specified as the SSH port parameter. The port specified in a preset can be overridden in the host name (for example, hostname.domain:2222), during the actual agent installation.

  3. You may need to download Sysinternals psexec.exe, in which case you will see the corresponding warning and a link to the Administration | Tools page where you can download it.

Starting the Build Agent

TeamCity build agents can be started manually or configured to start automatically.

Manual Start

To start the agent manually, run the following script:

  • for Windows: <installation path>\bin\agent.bat start

  • for Linux and macOS: <installation path>\bin\agent.sh start

Automatic Start

To configure the agent to be started automatically, see the corresponding sections:

  • Windows

  • Linux: configure a daemon process with the agent.sh start command to start it and the agent.sh stop command to stop it.

  • macOS

Automatic Agent Start under Windows

To run an agent automatically on the machine boot under Windows, you can either set up the agent to be run as a Windows service or use another way of the automatic process start.
Using the Windows service approach is the easiest way, but Windows applies some constraints to the processes run this way.
A TeamCity agent works reliably under Windows service provided all the requirements are met, but is often not the case for the build processes configured to be run on the agent.

That is why it is recommended to run a TeamCity agent as a Windows service only if all the build scripts support this. Otherwise, it is advised to use alternative OS-specific ways to start a TeamCity agent automatically.
One of the ways is to configure an automatic user logon on Windows start and then configure the TeamCity agent start (via agent.bat start) on the user logon (for example, via Windows Task Scheduler).

Build Agent as a Windows Service

In Windows, you may want to run TeamCity agent as a Windows service to allow it running without any user logged on. If you use the Windows agent installer, you have an option to install the service in the installation wizard.

The following instructions can be used to install the Windows service manually (for example, after .zip agent installation). This procedure should also be performed to create Windows services for the second and following agents on the same machine.

To install the service:

  1. Check if the service with the required name and id (see #4 below, service name is TeamCity Build Agent by default) is not present; if installed, remove it.

  2. Check that the wrapper.java.command property in the <agent home>\launcher\conf\wrapper.conf file contains a valid path to the Java executable in the JDK installation directory. You can use wrapper.java.command=../jre/bin/java for the agent installed with the Windows distribution. Make sure to specify the path of the java.exe file without any quotes.

  3. If you want to run the agent under user account (recommended) and not "System", add the wrapper.ntservice.account and wrapper.ntservice.password properties to the <agent home>\launcher\conf\wrapper.conf file with appropriate credentials

  4. (for second and following installations) Modify the <agent>\launcher\conf\wrapper.conf file so that the wrapper.console.title, wrapper.ntservice.name, wrapper.ntservice.displayname, and wrapper.ntservice.description properties have unique values within the computer.

  5. Run the <agent home>\bin\service.install.bat script under a user with sufficient privileges to register the new agent service. Make sure to start the agent for the first time only after it is configured as described.

To start the service:

  • Run <agent home>/bin/service.start.bat (or use standard Windows Services applet)

To stop the service:

  • Run <agent home>/bin/service.stop.bat (or use standard Windows Services applet)

You can also use the standard Windows net.exe utility to manage the service once it is installed.
For example (assuming the default service name):

net start TCBuildAgent

The <agent home>\launcher\conf\wrapper.conf file can also be used to alter the agent JVM parameters.

The user account used to run the build agent service must have enough rights to start/stop the agent service, as described above.

Automatic Agent Start under Linux

To run an agent automatically on the machine boot under Linux, configure a daemon process with the agent.sh start command to start it and the agent.sh stop command to stop it.

For systemd, see the example teamcityagent.service configuration file:

[Unit] Description=TeamCity Build Agent After=network.target [Service] Type=oneshot User=teamcityagent Group=teamcityagent ExecStart=/home/teamcityagent/agent/bin/agent.sh start ExecStop=-/home/teamcityagent/agent/bin/agent.sh stop # Support agent upgrade as the main process starts a child and exits then RemainAfterExit=yes # Support agent upgrade as the main process gets SIGTERM during upgrade and that maps to exit code 143 SuccessExitStatus=0 143 [Install] WantedBy=default.target

For init.d, refer to an example procedure:

1. Navigate to the services start/stop services scripts directory:

cd /etc/init.d/

2. Open the build agent service script:

sudo vim buildAgent

3. Paste the following into the file :

#!/bin/sh ### BEGIN INIT INFO # Provides: TeamCity Build Agent # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start build agent daemon at boot time # Description: Enable service provided by daemon. ### END INIT INFO #Provide the correct user name: USER="agentuser" case "$1" in start) su - $USER -c "cd BuildAgent/bin ; ./agent.sh start" ;; stop) su - $USER -c "cd BuildAgent/bin ; ./agent.sh stop" ;; *) echo "usage start/stop" exit 1 ;; esac exit 0

4. Set the permissions to execute the file:

sudo chmod 755 buildAgent

5. Make links to start the agent service on the machine boot and on restarts using the appropriate tool:

  • For Debian/Ubuntu:

sudo update-rc.d buildAgent defaults

  • For Red Hat/CentOS:

sudo chkconfig buildAgent on

Automatic Agent Start under macOS

For macOS, TeamCity provides the ability to load a build agent automatically when a build user logs in.

The recommended approach is to use launchd (LaunchAgent):

To configure an automatic build agent startup via launchd, follow these steps:

1. Install a build agent on a Mac via buildAgent.zip.

2. Prepare the conf/buildAgent.properties file (set agent name there, at least).

3. Make sure that all files under the buildAgent directory are owned by your_build_user to ensure a proper agent upgrade process.

4. Load the build agent via the command:

mkdir buildAgent/logs  # Directory should be created under your_build_user user sh buildAgent/bin/mac.launchd.sh load

Run these commands under the your_build_user account.

Wait for some time for the build agent to auto-upgrade from the TeamCity server. This can take up to several minutes. You can watch the process in the logs:

tail -f buildAgent/logs/teamcity-agent.log

5. When the build agent upgrades and successfully connects to TeamCity server, stop the agent:

sh buildAgent/bin/mac.launchd.sh unload

6. After the build agent upgrades from the TeamCity server, copy the buildAgent/bin/jetbrains.teamcity.BuildAgent.plist file to the $HOME/Library/LaunchAgents/ directory (you might have to create it). If you don't want TeamCity to start under the root permissions, specify the UserName key in the .plist file, for example:

<key>UserName</key> <string>your_build_user</string>

7. Configure your Mac system to automatically login as your_build_user, as described here.

8. Reboot.

On the system startup, the build user should automatically log in, and the build agent should start.

To quickly check that the build agent is running, use the following command:

launchctl list | grep BuildAgent 69722 0 jetbrains.teamcity.BuildAgent

Stopping the Build Agent

To stop the agent manually, run the <Agent home>\agent script with a stop parameter.

Use stop to request stopping after the current build finished.
Use stop force to request an immediate stop (if a build is running on the agent, it will be stopped abruptly (canceled)).
Under Linux, you have one more option top use stop kill to kill the agent process.

If the agent runs with a console attached, you may also press Ctrl+C in the console to stop the agent (if a build is running, it will be canceled).

Stopping the Agent Service on macOS

If a build agent has been started as a LaunchAgent service, it can be stopped using the launchctl utility:

launchctl unload $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent.plist # or launchctl remove jetbrains.teamcity.BuildAgent

Configuring Java

A TeamCity build agent is a Java application (supported Java versions).

A build agent contains two processes:

  • Agent Launcher — a Java process that launches the agent process

  • Agent — the main process for a Build Agent; runs as a child process for the agent launcher

The (Windows) .exe TeamCity distribution comes bundled with 64-bit Amazon Corretto 8.
If you run a previous version of the TeamCity agent, you will need to repeat the agent installation to update the JVM.

Using 64-bit JDK (not JRE) is recommended. JDK is required for some build runners like IntelliJ IDEA Project, Java Inspections, and Duplicates. If you do not have Java builds, you can install JRE instead of JDK.
On switching from 32- to 64-bit, you might need to double the -Xmx memory value for the main agent process (see related notes).

For the .zip agent installation you need to install the appropriate Java version. Make it available via PATH or available in one of the following places:

  • the <Agent home>/jre directory

  • in the directory pointed to by the TEAMCITY_JRE, JAVA_HOME or JRE_HOME environment variables (check that you only have one of the variables defined).

  • if you plan to run the agent via Windows service, make sure to set the wrapper.java.command property in the <agent home>\launcher\conf\wrapper.conf file to a valid path to the Java executable

Upgrading Java on Agents

If you are trying to launch an agent, and it is not able to find the required Java version (currently Java 8) in any of the default locations, the agent will report an error on starting, the process will not launch, and the agent will be shown as disconnected in the TeamCity UI.

If a build agent uses a Java version older than Java 8, you will see the corresponding warning on the agent's page and a health item in the web UI.

It is recommended to use latest Java 8, 64-bit version.
OpenJDK 8 (for example, bundled Amazon Corretto) 1.8.0_161 or later. Oracle Java 8 is also supported.

To update Java on agents, do one of the following:

  • If the agent details page in the TeamCity UI displays a Java version note with the corresponding action, you can switch to using newer Java: if the appropriate Java version of the same bitness as the current one is detected on the agent, the agent page provides an action to switch to using that Java automatically. Upon the action invocation, the agent process is restarted (once the agent becomes idle, i.e. finishes the current build if there is one) using the new Java.

  • (Windows) Since the build agent Windows installer comes bundled with the required Java, you can just manually reinstall the agent using the Windows installer (.exe) obtained from the TeamCity server Agents page. See installation instructions. It is important to uninstall the previous version of the agent before installing the updated agent: invoke Uninstall.exe in the agent home directory, clear all the "Remove" checkboxes, and click Uninstall.

  • Install a required Java on the agent into one of the standard locations, and restart the agent — the agent should then detect it and provide an action to use a newer Java in the web UI (see above).

  • Install a required Java on the agent and configure the agent to use it.

Installing Several Build Agents on the Same Machine

You can install several TeamCity agents on the same machine if the machine is capable of running several builds at the same time. However, we recommend running a single agent per (virtual) machine to minimize builds cross-influence and making builds more predictable. When installing several agents, it is recommended to install them under different OS users so that user-level resources (like Maven/Gradle/NuGet local artifact caches) do not conflict.

TeamCity treats all agents equally regardless of whether they are installed on the same or on different machines.

When installing several TeamCity build agents on the same machine, consider the following:

  • The builds running on such agents should not conflict by any resource (common disk directories, OS processes, OS temp directories).

  • Depending on the hardware and the builds' specifics, you may experience degraded building performance. Ensure there are no disk, memory, or CPU bottlenecks when several builds are run at the same time.

  • Preferably, agents should run under different OS users.

After having one agent installed, you can install additional agents by following the regular installation procedure (see an exception for the Windows service below), but make sure that:

  • The agents are installed in separate directories.

  • The agents have the distinctive workDir and tempDir directories in the buildAgent.properties file.

  • Values for the name and ownPort properties of buildAgent.properties are unique.

  • No build configurations specify the absolute path to the checkout directory (or, if necessary, you can enable the "clean checkout" option and make sure they do not run in parallel).

Usually, for a new agent installation you can just copy the directory of the existing agent to a new place except its temp, work, logs, and system directories. Then, modify conf/buildAgent.properties with the new name and ownPort values. Clear (delete or remove the value) the authorizationToken property and make sure the workDir and tempDir are relative/do not clash with another agent.

Configuring second build agent on macOS

If you want to start several build agents on macOS, repeat the procedure of installing and starting build agent with the following changes:

  • Install the second build agent in a different directory.

  • In conf/buildAgent.properties, specify a different agent name.

  • Do not run buildAgent/bin/mac.launchd.sh; instead

    • Create a copy of the $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent.plist file as $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent2.plist.

    • Edit the $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent2.plist file and set the following parameters:

      • the Label parameter to jetbrains.teamcity.BuildAgent2

      • the WorkingDirectory parameter to the correct path to the second build agent home

    • Start the second agent with the command launchctl load $HOME/Library/LaunchAgents/jetbrains.teamcity.BuildAgent2.plist.

To check that both build agents are running, use the following command:

launchctl list | grep BuildAgent 70599 0 jetbrains.teamcity.BuildAgent2 69722 0 jetbrains.teamcity.BuildAgent

Configuring second build agent on Windows

If you use Windows installer to install additional agents and want to run the agent as a service, you will need to perform manual steps as installing second agent as a service on the same machine is not supported by the installer: the existing service is overwritten (see also a feature request).

In order to install the second agent, it is recommended to install the second agent manually (using the .zip agent distribution). You can use the Windows agent installer and do not opt for service installation, but you will lose uninstall option for the initially installed agent this way.

After the second agent is installed, register a new service for it as mentioned in the section above.

Last modified: 14 October 2021
Installation Build Agent Configuration