Team city on linux

Supported Platforms and Environments

This page covers software-related environments TeamCity works with. For hardware-related notes, see this section.

Operating Systems

TeamCity Server

TeamCity Server is a web application that runs within a capable J2EE servlet container. It requires a Java SE JRE installation to run. See notes on how to install Java on a TeamCity server.

Supported Java Versions

Supported Java versions: OpenJDK and Oracle Java 8 (8u16 or later), 11, and 17 (32 or 64 bit). Using 64-bit Java is recommended.

The TeamCity server Windows installer and server Docker images come bundled with Amazon Corretto 64-bit Java 17.

For Apple ARM systems (for example, Apple M1 or M2), consider using a different version of Java, like Azul OpenJDK.

Java 8 support will be discontinued in one of the future TeamCity Server versions. If you use a non-bundled version of Java 8, we highly recommend that you migrate your server to Java 11 or 17.

Supported Platforms

The core features of TeamCity Server are platform-independent. See considerations on choosing the server platform.

Generally, all the recent versions of Windows, Linux, and macOS are supported. If you find any compatibility issues with any of the operating systems, let us know.

TeamCity Server is tested under the following operating systems:

• Linux (Ubuntu, Debian, RedHat, SUSE, and others)
• macOS
• Windows 7/7×64
• Windows Server 2008, 2012, 2016, 2019, 2022
• Server Core installation of Windows Server 2016
• Windows 10 and 11 under the Tomcat 8.5+ web application server

Reportedly works without known issues on:

• Windows 7+
• Windows Server 2008 R2
• Solaris
• FreeBSD
• IBM z/OS
• HP-UX

Windows XP/XP x64 are not supported.

Regarding architectural compatibility, TeamCity is not limited to any specific list. The verified and thoroughly tested architectures include:

If you are using a different architecture that is not explicitly mentioned above, you may expect the TeamCity server to support it, provided that your operating system is supported and a suitable Java Virtual Machine (JVM) option exists.

TeamCity Agent

TeamCity Agent is a standalone Java application. It requires a Java SE JRE installation to run. See notes on how to configure Java on agents.

Supported Java Versions

Supported Java versions: OpenJDK and Oracle Java 8-17. We recommend using the latest available version of JDK.

The TeamCity agent Windows installer and agent Docker images come bundled with Amazon Corretto 64-bit Java 17.

For Apple ARM systems (for example, Apple M1 or M2), consider using a different version of Java 17, like Azul OpenJDK.

Note that Java versions specified in this section are requirements to run the agent itself. Builds can utilize other versions installed on agent machines (for example, JDK 19).

Supported Platforms

TeamCity Agent is tested under the following operating systems:

• Linux
• macOS
• Windows 7/7×64
• Windows 10
• Windows Server 2003/2008, 2012, 2016, 2019, 2022
• Server Core installation of Windows Server 2016

• Windows XP/XP x64
• Windows 2000 (interactive mode only)
• Solaris
• FreeBSD
• IBM z/OS
• HP-UX

Regarding architectural compatibility, TeamCity is not limited to any specific list. The verified and thoroughly tested architectures include:

If you are using a different architecture that is not explicitly mentioned above, you may expect the TeamCity Agent to run on it, provided that your operating system is supported and a suitable Java Virtual Machine (JVM) option exists.

Browsers

The TeamCity web interface is mostly W3C-compliant, so any modern browser should work well with TeamCity. The recent versions of the following browsers have been specifically tested and reported to work correctly:

• Google Chrome
• Mozilla Firefox
• Safari under macOS
• Microsoft Edge
• Opera

Источник

Install TeamCity Server on Linux or macOS

Before installing the TeamCity server, you might want to estimate your system requirements and read about supported platforms.

Download TeamCity Server

Go to the JetBrains website and download the .tar.gz distribution with the «portable» version of the TeamCity server.

Or, you can install it from a Docker image. All the information related to the TeamCity Server Docker images is described on Docker Hub.

Specifics of the .tar.gz distribution:

• It includes a Tomcat version tested to work fine with the respective version of TeamCity. You can use an alternative Tomcat version, but other combinations are not guaranteed to work correctly.
• It is possible to configure the installation by changing the startup script and JRE options.
• It comes bundled with a build agent distribution and a startup script which allows for easy TeamCity server evaluation with one agent.
• It comes bundled with the devPackage for the TeamCity plugin development.

Install from tar.gz

We recommend running the TeamCity server under a dedicated user account.

It is highly recommended running the TeamCity server under a dedicated user account.

To install the TeamCity server, unpack the TeamCity.tar.gz archive. You can use the tar xfz TeamCity.tar.gz command under Linux * and WinZip, WinRar, or similar utility under Windows.

* We advise using GNU tar or the gtar xfz command for unpacking. For example, Solaris 10 tar is reported to truncate long file names and may cause ClassNotFoundException when using the server after unpacking.

Ensure that JRE or JDK are installed and the JAVA_HOME environment variable is pointing to the Java installation directory (see recommended Java versions).

Источник

Start TeamCity Agent

This page is only relevant for self-hosted build agents.

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

Manual Start

Automatic Start

Automatic Agent Start Under Windows

To run an agent automatically on a Windows machine launch, you can either set up the agent to run as a Windows service or use another method. 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 a Windows service provided all the requirements are met, but it is often not the case for the build processes configured to be run on the agent. This is why it is recommended running a TeamCity agent as a Windows service only if all your build scripts support this. Otherwise, it is advised to use alternative OS-specific methods to start a TeamCity agent automatically.
One of them 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 Windows Service

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

To run builds, the build agent must be started under a user with sufficient permissions for performing a build and managing the service. By default, a Windows service is started under the SYSTEM account which is not recommended for production use due to extended permissions this account has. To change it, use the standard Windows Services applet (Control Panel | Administrative Tools | Services) and change the user for the TeamCity Build Agent service.

The following instructions can be used to install a 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.

1. Check if the service with the required name and ID (see Step 4; the 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 \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 from the Windows distribution file. Make sure to specify the path of the java.exe file without any quotes.
3. If you want to run the agent under a user account (recommended) and not «System», add the wrapper.ntservice.account and wrapper.ntservice.password properties to the \launcher\conf\wrapper.conf file with appropriate credentials.
4. (for the second and following agents on the same machine) Modify the \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 OS.
5. Run the \bin\service.install.bat script under a user with sufficient privileges to register a new agent service. Make sure to start the agent for the first time only after it is configured as described.

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):

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

Note that the user account used to run the build agent service must have enough rights to start/stop the agent service.

Automatic Agent Start Under Linux

To run an agent automatically on a Linux machine launch, 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 this example procedure:

Navigate to the services` scripts directory:

#!/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

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 via buildAgent.zip .
2. Prepare the conf/buildAgent.properties file (set at least the agent name).
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

Stop Build Agent

To stop the agent manually, run the \agent script with the 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 can also 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).

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

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

Источник