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 TeamCity 2018.1 documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.

Skip to end of metadata
Go to start of metadata

This is a runner for Ant build.xml files. TeamCity 10.0.x comes bundled with Ant 1.9.7, TeamCity 2017.1 - Ant 1.9.9.

In this section:

Testing Frameworks Support

The TeamCity Ant runner supports the JUnit and TestNG frameworks. When tests are run by the junit and testng tasks directly within the script, TeamCity reports tests on the fly.

 By using the <parallel> tag in your Ant script, it is possible to have the JUnit and TestNG tasks run in parallel. TeamCity supports this and should concurrently log the parallel processes correctly.

Reporting and Logging

TeamCity collects detailed data from  Ant as to the performed activities, provides structured error reporting, and reports tests. However, you can start a build with no specific reporting or to turn off TeamCity-specific logging:

  • To disable TeamCity-specific reporting in Ant, use teamcity.ant.listener.enabled=false build configuration parameter
  • To disable JUnit reporting, use teamcity.ant.junit-support.enabled=false system property 
  • To disable TestNG reporting,  use teamcity.ant.testng-support.enabled=false system property

Ant Runner Settings

Ant Parameters



Path to build.xml file

If you choose the option, you can type the path to an Ant build script file of the project. The path is relative to the project root directory. Alternatively, click to choose the file using the VCS repository browser.

Build file content

If you choose this option, click the Type build file content link and type the source code of your custom build file in the text area. Note that the text area is resizeable. Use the Hide link to close the text area.

Working directory

Specify the build working directory if it differs from the checkout directory.


Use this text field to specify valid Ant targets as a list of space-separated strings. The available targets can be viewed in the Web UI by clicking the icon next to the field and added by checking the appropriate boxes. If this field is left empty, the default target specified in the build script file will be run.

Ant home path

Specify the path to the distributive of your custom Ant. You do not need to specify this parameter if you are going to use the Ant 1.9.7 distributive bundled with TeamCity.


Please note, that you should use Ant 1.7 if you want to run JUnit4 tests in your builds.

Additional Ant command line parameters

Optionally, specify additional command line parameters as a space-separated list. For example, you can specify the ant-net-tasks Tool here (see below).

ant-net-tasks Tool

The Ant build runner comes with a bundled tool, ant-net-tasks, which includes the jar files required for network tasks, such as FTP, sshexec, scp and mail.
It also contains missing link Ant task which can be used for REST requests.

To use the tool, specify -lib "%teamcity.tool.ant-net-tasks%" in Additional Ant command line parameters of the runner settings.

Java Parameters




Select a JDK. This section details the available options. The default is JAVA_HOME environment variable or the agent's own Java.

JDK home path

The option is available when <Custom> is selected above. Use this field to specify the path to your custom JDK used to run the build. If the field is left blank, the path to JDK Home is read either from the JAVA_HOME environment variable on agent the computer, or from the env.JAVA_HOME property specified in the build agent configuration file (buildAgent.properties). If these values are not specified, TeamCity uses the Java home of the build agent process itself.

JVM command line parameters

You can specify such JVM command line parameters, e.g. maximum heap size or parameters enabling remote debugging. These values are passed by the JVM used to run your build.

Test Parameters

Tests reordering works the following way: TeamCity provides tests that should be run first (test classes), after that, when a JUnit task starts, it checks whether it includes these tests. If at least one test is included, TeamCity generates a new fileset containing included tests only and processes it before all other filesets. It also patches other filesets to exclude tests added to the automatically generated fileset. After that JUnit starts and runs as usual.



Reduce test failure feedback time:

Use the following two options to instruct TeamCity to run some tests before others.

  • Run recently failed tests first - If checked,TeamCity will first run tests failed in the previous finished or running builds as well as tests having a high failure rate (so called blinking tests).
  • Run new and modified tests first - If checked, TeamCity will first run the tests added or modified in the change lists included in the running build.



If both options are enabled at the same time, the tests of the new and modified tests group will have higher priority, and will be executed first.

Docker Settings

In this section, you can specify a Docker image which will be used to run the build step.

Run step within Docker container

Specify a Docker image here. TeamCity will start a container from the specified image and will try to run this build step within this container.  

Pull image explicitly (since TeamCity 2017.2)

If the checkbox is enabled, docker pull <imageName> will be run before the docker run command.

Additional docker run arguments

The Edit arguments field allows specifying additional options for docker run. The default argument is --rm.

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 etc. 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, and TeamCity passes most environment variables from the build agent into the docker process.

After the build step with the Docker wrapper, a build agent will run 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 variable, this network is passed to the started docker run command with --network switch. 

It is possible to provide extra parameters for the docker run command, for instance, provide an additional volume mapping.

Code Coverage

To learn about configuring code coverage options, refer to the Configuring Java Code Coverage page.

See also:

Administrator's Guide: Configuring Java Code Coverage

1 Comment

  1. I have a question about REST API