Ipr (deprecated)

Edit page Last modified: 10 November 2021

This runner provides ability to build IntelliJ IDEA projects in TeamCity.
It is superseded by IntelliJ IDEA Project runner.

This page contains reference information about the IPR build runner fields.

Ipr Runner Deprecation

Since TeamCity 6.0 Ipr runner is deprecated in favor of IntelliJ IDEA project runner which uses another implementation approach. In one of the following major TeamCity releases all build configurations with Ipr runner will be automatically converted to IntelliJ IDEA project runner. Since the runners may function differently in specific configurations it is highly recommended to change your current Ipr runner-based configurations to the new runner and check your settings before the final Ipr runner disabling. Please also use the IntelliJ IDEA project runner for all newly created projects and let us know if you have any issues with it.

Apart from differences in the scope of supported IntelliJ IDEA project features, the runners are also different in approach to tests running and coverage.
Namely:

  • EMMA coverage is not supported by IntelliJ IDEA project runner. We recommend migrating to IntelliJ IDEA coverage engine if you used EMMA

  • in IntelliJ IDEA project runner JUnit tests are launched via IntelliJ IDEA shared run configurations as opposed to Ant's <junit> task in Ipr runner.

Here are the recommended steps to perform the migration from Ipr to IntelliJ IDEA project runner:

  1. If your existing Ipr runner has JUnit Test Runner Settings configured, backup all the settings of the section, for example, into a text file.

  2. If you have code coverage settings configured, save these settings also. (See also related issue)

  3. Change the runner type to IntelliJ IDEA Project. All your settings will be migrated except for JUnit and code coverage options.

  4. To restore JUnit tests you will need to create a shared run configuration in IntelliJ IDEA and commit the corresponding file into the version control. The name of the run configuration can then be specified in the Run configurations to execute area.

  5. For coverage, configure code coverage options anew using your saved settings.

IntelliJ IDEA Project Settings

Option

Description

Path to the project

Use this field to specify the path to the project file (.ipr) or path to the project directory (root directory of the project that contains .idea directory). This information is required by this build runner to understand the structure of the project.

The path should be relative to the checkout directory.

Detect global libraries and module-based JDK in the *.iml files

If this option is checked, all the module files will be automatically scanned for references to the global libraries and module JDKs when saved. This helps you ensure all references will be properly resolved.

warning

When this option is selected, the process of opening and saving the build runner settings may become time-consuming, because it involves loading and parsing all project module files.

Check/Reparse Project

Click to reparse the project and import build settings right from the IDEA project, for example the list of JDKs.

note

If you update your project settings in IntelliJ IDEA — add new JDKs, libraries, don't forget to update build runner settings by clicking Check/Reparse Project.

Working directory

Enter a path to a Build Working Directory, if it differs from the Build Checkout Directory.

Optional, specify if differs from the checkout directory.

Unresolved Project Modules and Path Variables

This section is displayed, when an IntelliJ IDEA module file (.iml) referenced from IPR-file:

  • cannot be found

  • allows you to enter the values of path variables used in the IPR-file

To refresh values in this section click Check/Reparse Project.

Option

Description

<path_variable_name>

This field appears, if the project file contains path macros, defined in the Path Variables dialog of IntelliJ IDEA's Settings dialog. In the Set value to field, specify a path to project resources, to be used on different build agents.

Project JDKs

This section provides the list of JDKs detected in the project.

Option

Description

JDK Home

Use this field to specify JDK home for the project.

note

For Inspections and Duplicate Finder builds, this JDK will be used internally to resolve the Java API used in your project.
To run the build process itself the JDK specified in the JAVA_HOME environment variable will be used.

JDK Jar File Patterns

Click this link to open a text area, where you can define templates for the .jar files of the project JDK. Use Ant rules to define the .jar file patterns.
The default value is used for Linux and Windows operating systems:

jre/lib/*.jar

For macOS, use the following lines:

lib/*.jar

../Classes/*.jar

IDEA Home

If your project uses the IDEA JDK, specify the location of IDEA home directory

IDEA Jar Files Patterns

Click this link to open a text area, where you can define templates for the .jar files of the IDEA JDK.

note

You can use references to external properties when defining the values, like %system.idea_home% or %env.JDK_1_3%. This will add a requirement for the corresponding property.

Additional Pre/Post Processing (Ant)

Option

Description

Run before build

In the appropriate fields, enter the Ant scripts and targets (optional) that you want to run prior to starting the build. The path to the Ant file should be relative to the project root directory.

Run after build

In the appropriate fields, enter the Ant scripts and targets (optional) that you want to run after the build is completed. The path to the Ant file should be relative to the project root directory.

JUnit Test Runner Settings

tip

JUnit test settings map to the attributes of JUnit task. For details, refer to Apache documentation.

Option

Description

Test patterns

Click the Type test patterns link, and specify the required test patterns in a text area.
These patterns are used to generate parameters of the batchtest JUnit task section. Each pattern generates either include or exclude section. These patterns are also used to compose classpath for the test run. Each module mentioned in the patterns adds its classpath to the whole classpath.
Each pattern should be placed on a separate line and has the following format:

[-]moduleName:[testFileNamePattern]

where:

  • [-]: If a pattern starts with a minus character, the corresponding files will be excluded from the build process.

  • moduleName: this name can contain wildcards.

  • [testFileNamePattern]: Default value for testFileNamePattern is **/*Test.java, i.e. all files ending with Test.java in all directories. You can use Ant syntax for file patterns. The sample below includes all test files from modules ending with "test" and excludes all files from packages containing the "ui" subpackage:

*test:**/*Test.java
-*:**/ui/**/*.java

Search for tests

In IDEA project, a user can mark a source code directory as either sources or test root. This drop-down menu allows you to specify directories to look for tests:

  • Throughout all project sources: look for tests in both sources and test directories of your IDEA project.

  • In test sources only: look through the directories marked as tests root only.

Classpath in Tests

By default the whole classpath is composed of all classpaths of the modules used to get tests from. The following two options define whether you will use the default classpath, or take it from the specified module.

Override classpath in tests

If this option is checked, you can define test classpath from a single, explicitly specified module.

Module name to use JDK and classpath from

If the option Override classpath in tests is checked, you have to specify the module, where the classpath to be used for tests is specified.

JUnit Fork mode

Select the desired fork mode from the combo box:

  • Do not fork: fork is disabled.

  • Fork per test: fork is enabled, and each test class runs in a separate JVM

  • Fork once: fork is enabled, and all test classes run in a single JVM

New classloader instance for each test

Check this option, if you want a new classloader to be instantiated for each test case. This option is available only if Do not fork option is selected.

Include Ant runtime

Check this option to add Ant classes, required to run JUnit tests. This option is available if fork mode is enabled (Fork per test or Fork once).

JVM executable

Specify the command that will be used to invoke JVM. This option is available if fork mode is enabled (Fork per test or Fork once).

Stop build on error

Check this option, if you want the build to stop if an error occurs during test run.

JVM command line parameters for JUnit

Specify JVM parameters to be passed to JUnit task.

Tests working directory

Specify the path to the working directory for tests.

Tests timeout

Specify the lapse of time in milliseconds, after which test will be canceled. This value is ignored, if Do not fork option is selected.

Reduce test failure feedback time

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

tip

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.

Run recently failed tests first

If checked, in the first place TeamCity will run tests failed in previous finished or running builds as well as tests having high failure rate (a so called blinking tests)

Run new and modified tests first

If checked, before any other test, TeamCity will run tests added or modified in change lists included in the running build.

note

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

Verbose Ant

Check this option, if the generated JUnit task has to produce verbose output in ant terms.

Code Coverage

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