TeamCity 2020.2 Help

Build Failure Conditions

TeamCity allows changing the conditions under which a build is marked as failed. You can adjust these build failure conditions in Build Configuration Settings | Failure Conditions

Common build failure conditions

In the Common Failure Conditions block, you can specify how exactly TeamCity will fail builds:

Additional Failure Conditions

You can instruct TeamCity to mark a build as failed if some of its metrics (for example, code coverage or artifacts size) have changed compared to another build. For instance, you can mark a build as failed if the code duplicates number is higher than in the previous build.

Another build failure condition causes TeamCity to mark build as failed when a certain text is present in the build log.

To add such failure condition, click Add build failure condition and select from the list:

Fail build on metric change

When your build uses code examining tools like code coverage, duplicates finders, or inspections, it generates various numeric metrics. For these metrics, you can specify a threshold which, when exceeded, will fail a build.

In general, there are two ways to configure this build fail condition:

Values from the following builds can be used as the basis for comparing build metrics:

  • last successful build

  • last pinned build

  • last finished build

  • build with specified build number

  • last finished build with specified tag.

By default, TeamCity provides the wide range of build metrics:

  • artifacts size(bytes) – size of artifacts, excluding internal artifacts under the .teamcity directory

  • build duration (secs)

  • number of classes

  • number of code duplicated

  • number of covered classes

  • number of covered lines

  • number of covered methods

  • number of failed tests

  • number of ignored tests

  • number of inspection errors

  • number of inspection warnings

  • number of lines of code

  • number of methods

  • number of passed tests

  • number of tests

  • percentage of block coverage

  • percentage of class coverage

  • percentage of line coverage

  • percentage of method coverage

  • percentage of statement coverage

  • test duration (secs)

  • total artifacts size (bytes) – size of all artifacts including internal ones

Note that since TeamCity 9.0, the way TeamCity counts tests has changed.

Adding custom build metric

You can add your own build metric. To do so, you need to modify the TeamCity configuration file <TeamCity_Data_Directory>/config/main-config.xml and add the following section under the server node there:

<build-metrics> <statisticValue key="myMetric" description="build metric for number of files"/> </build-metrics>

If your build publishes the myMetric value, you can use it as a criterion for a build failure.

Fail build on specific text in build log

TeamCity can inspect all lines in a build log for some particular text occurrence that indicates a build failure. When matching lines, the time and block name prefixes preceding each log message are ignored.

To configure this build failure condition, specify:

  • a string or a Java Regular Expression whose presence/absence in the build log is an indicator of a build failure,

  • a failure message to be displayed on the build results page when a build fails due to this condition.

Stopping build immediately

You can stop a build immediately on encountering a specified text in the build log or when a certain build metric, specified using the Fail build on metric change condition, is exceeded.

Last modified: 31 August 2020