Skip to end of metadata
Go to start of metadata

Note that you can create a new Maven-based build configuration automatically from URL, and set up a dependency build trigger, if a specific Maven artifact has changed.

Icon

Remote Run Limitations related to Maven runner
As a rule, a personal build in TeamCity doesn't affect any "regular" builds run on the TeamCity server, and its results are visible to its initiator only. However, in case of using Maven runner, this behavior may differ.
TeamCity doesn't interfere anyhow with the Maven dependencies model. Hence, if your Maven configuration deploys artifacts to a remote repository, they will be deployed there even if you run a personal build. Thereby, a personal build may affect builds that depend on your configuration.
For example, you have a configuration A that deploys artifacts to a remote repository, and these artifacts are used by configuration B. When a personal build for A has finished, your personal artifacts will appear in B. This can be especially injurious, if configuration A is to produce release-version artifacts, because proper artifacts will be replaced with developer's ones, which will be hard to investigate because of Maven versioning model. Plus these artifacts will become available to all dependent builds, not only to those managed by TeamCity.
To avoid this, we recommend not using remote run for build configurations which perform deployment of artifacts.

On this page:

 Maven runner settings

Option

Description

Goals

In the Goals field, specify the sequence of space-separated Maven goals that you want TeamCity to execute.
Some Maven goals can use version control systems, and, thus, they may become incompatible with some VCS checkout modes. If you want TeamCity to execute such a goal:

  • Select "Automatically on agent" in the VCS Checkout Mode drop-down list on the Version Control Settings page. This makes the version control system available to the goal execution software.
    (info) To use the release:prepare goal with Perforce VCS, see the section below.

Path to POM file

Specify the path to the POM file relative to the build working directory.
By default, the property contains a pom.xml file. If you leave this field blank, the same value is put in this field. The path may also point to a subdirectory, and as such <subdirectory>/pom.xml is used.

Additional Maven command line parameters

Specify the list of command line parameters.

Icon

The following parameters are ignored: -q, -f, -s (if User settings path is provided)

Working directory

Specify the Build Working Directory if it differs from the build checkout directory.

Maven Settings

 Choose the Maven version you want to use. Since TeamCity 2017.1, you can manage the installed versions.

<Auto>

The path to Maven installation is taken from the M2_HOME environment variable, otherwise the current default version is used.

<Default>

The bundled version 3.0.5 is used as default. Since TeamCity 2017.1, you can change the defaults.

<Custom>

Provide a path to a custom Maven version.


User Settings

Specify what kind of user settings to use here. This is equivalent to the Maven command line option -s or --settings. The available options are:

<Default>

Settings are taken from the default Maven locations on the agent. For the server logic, see Maven Server-Side Settings.

<Custom>

Enter the path to an alternative user settings file. The path should be valid on agent and also on the server, see Maven Server-Side Settings.

Predefined settings

If there are settings files uploaded to the TeamCity server via the administration UI, you can select one of the available options here. To upload settings file to TeamCity, click Manage settings files.
Maven settings are defined on the project level. You can see the settings files defined in the current project or upload files on the Project Settings page using Maven Settings. The files will be available in the project and its subprojects. The uploaded files are stored in the <TeamCity Data Directory>/config/projects/%projectID%/pluginData/mavenSettings directory. If necessary, they can be edited right there. The uploaded files are used both for the agent and server-side Maven functionality.
If Custom or Predefined settings are used, the path to the effective user settings file is available inside the maven process as the teamcity.maven.userSettings.path system property.

  

Java Parameters

Option

Description

JDK

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.
Example:

Local Artifact Repository Settings

Select Use own local repository for this build configuration to isolate this build configuration's artifacts repository from other local repositories.

Incremental Building

Select the Build only modules affected by changes check box to enable incremental building of Maven modules. The general idea is that if you have a number of modules interconnected by dependencies, a change most probably affects (directly or transitively) only some of them; so if we build only the affected modules and take the result of building the rest of the modules from the previous build, we will get the overall result equal to the result of building the whole project from scratch with less effort and time.

Since Maven itself has very limited support for incremental builds, TeamCity uses its own change impact analysis algorithm for determining the set of affected modules and uses a special preliminary phase for making dependencies of the affected modules.

First TeamCity performs own change impact analysis taking into account parent relationship and different dependency scopes and determines affected modules. Then the build is split into two sequential Maven executions.

The first Maven execution called preparation phase is intended for building the dependencies of the affected modules. The preparation phase is to assure there will be no compiler or other errors during the second execution caused by the absence or inconsistency of dependency classes.

The second Maven execution called main phase executes the main goal (for example, test), thus performing only those tests affected by the change.

Also check a related blog post on the topic.

Docker Settings

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

SettingDescription
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 EAP2)

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

After the build step with 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 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

Coverage support based on IDEA coverage engine is added to Maven runner. To learn about configuring code coverage options, please refer to the Configuring Java Code Coverage page.

Icon

Note: only Surefire version 2.4 and higher is supported.

Icon

If you have several build agents installed on the same machine, by default they use the same local repository. However, there are two ways to allocate a custom local repository to each build agent:

  • Specify the following property in the teamcity-agent/conf/buildAgent.properties:

    For instance, %system.agent.work.dir%/m2-repository

  • Run each build agent under different user account.

Maven Release with Different VCSs

To run the release:prepare maven task with different VCS's supported by TeamCity, make sure you're using at least 2.0 version of the Maven Release Plugin.

Using Maven Release with Perforce

Check the following:

1. Use ticket-based authentication for Maven Release plugin.
2. Make sure that your release:prepare maven task works when it is run from the command line without TeamCity.

In the Perforce VCS Root Settings of your build configuration in TeamCity:

1. Enable the checkout on agent.
2. Enable Use ticket-based authentication in Perforce VCS root settings.
3. Make sure your build agent environment doesn't have any occasional P4 variables which can interfere with the execution of Maven Release Plugin.
4. Specify release:prepare in the Goals field of the Maven build step and run the build.

Using Maven Release with Git VCS 


1. Use Git SSH URL as SCM URL in your pom.xml.
2. Make sure that your release:prepare maven task works when it is run from the command line without TeamCity.

On the TeamCity agent:
1. Make sure that the agent has Git installed and added to the agent's $PATH on Unix-like OS's and to %PATH% environment variable on Windows .
2. On the agent, set your account's identity by executing 

3. Make sure your Git VCS is added to the known hosts database on the agent.

On the TeamCity server:
1.Upload Git SSH key to your TeamCity server.

In the settings for your build configuration in TeamCity:
2. On the the Version Control Settings page, enable the checkout on agent.
3. In your Git VCS root, enable Private Key authentication.
4. Add the SSH Agent Build feature to your configuration.
5. Specify release:prepare in the Goals field of the Maven build step and run the build.

 


See also: