Mac OS X agents: hang up Follow. Anton Iakimov Created July 02, 2014 16:38. Hello Jetbrains and TC community! Our company has issues for Mac OS X. They are hanging up periodicaly in different phase of build proccess. 5848 -rw-r-r- 1 qa staff 2990096 2 Jul 15:25 teamcity-agent.log 16688 -rw-r-r- 1 qa staff 8543728 2 Jul 15:21 teamcity. Hi All, We are having some issues setting up a new MAC Agent. We need the MAC Agent to support Powershell which is should acording to this: Since TeamCity 2017.1, TeamCity provides support for PowerShell on Linux and Mac OS How should this be setup on the MAC Agent? Sharma is somewhat correct, and KIR has it completely correct. I needed a build configuration for each server, Mac and Windows. Then I set a snapshot dependency from the Windows build on the Mac build (to make sure the Mac version builds completely first) and a artifact dependency from the same (to copy the resulting build output from the Mac to the Windows box).
Skip to end of metadataGo to start of metadataYou are viewing documentation of TeamCity 7.x, which is not the most recently released version of TeamCity. Please refer to the listing to choose another version. |
This page covers:
Before you can start customizing projects and creating build configurations, you need to configure build agents. Icon
Installing Additional Build AgentsBefore the installation, please review Known Issues#Conflicting Software section. Necessary OS and environment permissionsPlease note that in order to run a TeamCity build agent, the user account under which the Agent is running should have the correct privileges, as described below. Network
If the agent is behind NAT and cannot be accessed by any of addresses of agent machine network interfaces, please specify ownAddress in the agent config. Common
Windows
For granting necessary permissions for unprivileged users, see Microsoft SubInACL utility. For example, to grant Start/Stop rights you might need to execute subinacl.exe /service browser /grant=<login name>=PTO command.Linux
Build-related Permissions The build process is launched by TeamCity agent and thus shares the environment and is executed under the same OS user that TeamCity agent runs under. Please ensure that TeamCity agent is configured accordingly. See Known Issues for related Windows Service Limitations. Server-Agent Data TransfersIcon Please be sure to read through this section if you plan to deploy agent and server into non-secure network environments. During TeamCity operations, both server establishes connections to the agents and agents establish connections to the server. Please note that by default, these connections are not secured and thus are exposing possibly sensitive data to any third party that can listen to the traffic between the server and the agents. Moreover, since the agent and server can send 'commands' to each other an attacker that can send HTTP requests and capture responses can in theory trick agent into executing arbitrary command and perform other actions with a security impact. It is recommended to deploy agents and the server into a secure environment and use plain HTTP for agents-to-server communications as this reduces transfer overhead. It is possible to setup a server to be available via HTTPS protocol, so all the data traveling through the connections established from an agent to the server (incl. download of build's sources, artifacts of builds, build progress messages and build log) can be secured. See Using HTTPS to access TeamCity server for configuration details. However, the data that is transferred via the connections established by the server to agents (build configuration settings, i.e., all the settings configured on the web UI including VCS root data) is passed via unsecured HTTP connection. For the time being TeamCity does not provide internal means to secure this data transfers (see/vote for TW-5815). If you want to secure the data you need to establish appropriate network security configurations like VPN connections between agent and server machines. Installing ProcedureYou can install build agent using any of the following installation options available: After installation, please configure the agent specifying its name and address of TeamCity server in its conf/buildAgent.properties file.Then start the agent. When the newly installed agent connects to the server for the first time, it appears on the Unauthorized agents tab under Agents , where administrators can authorize it. Please note that the tab is only visible for administrators/users with appropriate permission.Icon Agents will not run builds until they are authorized in the TeamCity web UI. The agent running on the same computer as the server is authorized by default. If the agent does not seem to run correctly, please check the agent logs. Installing via Java Web Start
Installing via a MS Windows installer
Installing via ZIP File
Installing via Agent PushTeamCity provide functionality that allows to install a build agent to a remote host. Currently supported combinations of server host platform and targets for build agents are:
Icon SSH note Make sure 'Password' or 'Public key' authentication is enabled on the target host according to preferred authentication method. There are several requirements for the remote host that should be met:
Installation Procedure
Icon You can use Agent Push presets in Amazon EC2 Cloud profile settings to automatically install build agent to started cloud instance. Starting the Build AgentTo start the agent manually, run the following script:
To configure agent to be started automatically, see corresponding sections: Windows Mac OS X Linux: configure daemon process with agent.sh start command to start it and agent.sh stop command to stop it.Stopping the Build AgentTo stop the agent manually, run the <Agent home>agent script with a stop parameter.Use stop to request stopping after current build finished.Use stop force to request 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). Automatic Agent Start under WindowsTo run agent automatically on machine boot under Windows you can either setup agent to be run as Windows service or use another way of automatic process start. Using Windows service approach is the easiest way, but Windows applies some constraints to the processes run in this way. TeamCity agent can work OK under Windows service (provided all the requirements are met), but is often not the case for the build processes that you will configure to be run on the agent. That is why it is advised to run TeamCity agent as use Windows service only if all the build scripts support this. Otherwise, it is adviced to use alternative ways to start TeamCity agent automatically. One of the ways is to configure automatic user logon on Windows start and then configure TeamCity agent start (via agent.bat start ) on user logon.Build Agent as a Windows ServiceIn Windows, you may want to use the build agent Windows service to allow the build agent to run without any user logged on. If you use Windows agent installer you have an option to install the service in the installation wizard. Service system account IconTo run builds, the build agent should be started under a user with enough permissions for performing a build and managing the service. By default, Windows service in started under SYSTEM account. To change it, use the standard Windows Services applet (Control Panel|Administrative Tools|Services) and change the user for TeamCity Build Agent service.The following instruction can be used to install the service manually. This procedure should also be performed to install second and following agents on the same machine as Windows services To install the service:
To start the service:
To stop the service:
You can also use Windows net.exe utility to manage the service once it is installed.For example (assuming the default service name): The file <agent home>launcherconfwrapper.conf can also be used to alter agent JVM parameters.User account that is used to run build agent service should have enough rights to start/stop agent service. Icon A method for assigning rights to manage services is to use the Subinacl.exe utility from the Windows 2000 Resource Kit. The syntax for this is: SUBINACL /SERVICE MachineNameServiceName /GRANT=[DomainName]UserName[=Access] See http://support.microsoft.com/default.aspx?scid=kb;en-us;288129 Using LaunchDaemons Startup Files on MacOSxFor MacOSx, TeamCity provides ability to load a build agent automatically at the system startup using LaunchDaemons plist file.To use LaunchDaemons plist file:
If you need to configure TeamCity agent environment you can change <TeamCity Agent Home>/launcher/conf/wrapper.conf (JSW configuration). For example, to make the agent see Mono installed using MacPorts on Mac OS X agent you will need to add the following line:Configuring JavaTeamCity Agent is a Java application and it requires JDK version 1.6 or later to work. Oracle JDK is recommended. (Windows) .exe TeamCity distribution comes with appropriate Java bundled. If you run previous version of TeamCity agent you might need to repeat agent installation to update used Java. Using x32 bit JDK is recommended. If you do not have Java builds, you may install JRE instead of JDK. Using of x64 bit Java is possible, but you might need to double -Xmx and -XX:MaxPermSize memory values for the main agent process (see Configuring Build Agent Startup Properties and alike section for the server). For .zip agent installation you need to install appropriate Java version (make it available via PATH) or available in one of the following places:
You can download Java installation from Oracle, select Java SE, JDK, version 1.6, 32 bit. Upgrading Java on AgentsIf a build agent uses a Java version older than it is required by agent (Java 1.6 currently), you will see the corresponding warning at the agent's page. This may happen when upgrading to a newer TeamCity version, which doesn't support an old Java version anymore. To update Java on agents you can do one of the following:
Installing Several Build Agents on the Same MachineTeamCity treats equally all agents no matter if they are installed on the same or on different machines. However, before installing several TeamCity build agents on the same machine, please consider the following:
After having one agent installed, you can install additional agents by following the regular installation procedure (see exception for the Windows service below), but make sure that:
Moreover, make sure you don't have build configurations with absolute checkout directory specified (alternatively, make sure such build configurations have 'clean checkout' option enabled and they cannot be run in parallel). Usually, for a new agent installation you can just copy the directory of existing agent to a new place with the exception of its 'temp', 'work', 'logs' and 'system' directories. Then, modify conf/buildAgent.properties with a new 'name', 'ownPort' values. Please also clear (delete or remove value) for 'authorizationToken' property and make sure 'workDir' and 'tempDir' are relative/do not clash with another agent.If you want to install additional agents as services under Windows, do not opt for service installation during installer wizard or install manually (see also a feature request), then modify the <agent>launcherconfwrapper.conf file so that wrapper.console.title , wrapper.ntservice.name , wrapper.ntservice.displayname and wrapper.ntservice.description properties have unique values within the computer. Then run <agent>binservice.install.bat script under user with sufficient privileges to register the new agent service.See above for the service start/stop instructions. See also: |
Page:Build Agent Configuration
TeamCity provides the Docker Wrapper extension for Command Line, Maven, Ant, Gradle, .NET CLI (dotnet), and PowerShell runners. This extension allows running a build step inside the specified Docker image. Each of the supported runners has the dedicated Docker settings section.
![Agent Agent](/uploads/1/0/5/7/105760537/979264690.png)
Requirements
The integration requires Docker installed on the build agents.
Supported Environments
TeamCity Docker Support can run on Mac, Linux, and Windows build agents. It uses the
docker
executable on the build agent machine, so it should be runnable by the build agent user.- On Linux, the integration will run if the installed Docker is detected.
- On Windows, the integration works for Linux and Windows container modes.
- On macOS, the official Docker support for Mac should be installed for the user running the build agent.
Docker Settings
In the Docker Settings section of the build step settings, you can specify a Docker image which will be used to run the build step. Once an image is specified, all the following options become available.
Setting | Description |
---|---|
Run step within Docker container | Specify a Docker image name as stated in the Docker Hub. TeamCity will start a container from the specified image and will try to run this build step within this container. For example, ruby:2.4 will run the step within the Ruby container, version 2.4. |
Docker image platform | Select <Any> (default), Linux, or Windows. |
Pull image explicitly | If enabled, the image will be pulled from the Hub repository via docker pull <imageName> before the docker run command is launched. |
Additional docker run arguments | Allows specifying additional options for docker run . The default argument is --rm , but you can provide more, for instance, add an additional volume mapping.In this field, you cannot reference environment variables using %env.FOO_BAR% syntax because TeamCity does not pass environment variables from a build agent into a Docker container.If you need to reference an environment variable on an agent, define the configuration parameter system.FOO_BAR=env_var_value in buildAgent.properties and reference it via %system.FOO_BAR% . |
How It Works
What Is Teamcity
![Teamcity Teamcity](/uploads/1/0/5/7/105760537/710184520.png)
Technically, the command of the build runner is wrapped in a shell script, and this script is executed inside a Docker container with the
docker run
command. All the details about the started process, text of the script, and so on, are written into the build log (the Verbose mode enables viewing them).The checkout directory and most build agent directories are mapped inside the Docker process.
At the end of the build step with the Docker wrapper, a build agent runs the
chown
command to restore access of the buildAgent
user to the checkout directory. This mitigates a possible problem when the files from a Docker container are created with the root
ownership and cannot be removed by the build agent later.If the process environment contains the
TEAMCITY_DOCKER_NETWORK
environment variable set by the previous Docker Compose build step, this network is passed to the started docker run
command with the --network
switch.Teamcity Agent Parameters
Environment Variables Handling
Teamcity Agent Disconnected
TeamCity passes environment variables from the build configuration into the Docker process, but it does not pass environment variables from the build agent, as they may not be relevant to the Docker container environment. The list of the passed environment variables can be seen in Verbose mode in the build log.