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
tip
To fail a build if sufficient disk space cannot be freed for the build, see the Free disk space build feature.
Common build failure conditions
In the Common Failure Conditions block, you can specify how exactly TeamCity will fail builds:
- if it runs longer than ... minutes: Enter a value in minutes to enable execution timeout for a build. If the specified amount of time is exceeded, the build is automatically canceled.
Unless set to 0, this build configuration setting overrides the server-wide default execution timeout specified in Administration | Global Settings.
The default value of 0 means that no limit is set by the build configuration. If there is a server-wide default execution timeout, this default will be used.
This option helps to deal with hanging builds and maintains agent efficiency.
if the build process exit code is not zero: Mark the build as failed if the build process doesn't exit successfully.
- if at least one test failed: Mark the build as failed if the build fails at least one test. If this option is disabled, the build can be marked successful even if it fails to pass a number of tests. Regardless of this option, TeamCity will run all build steps.
support test retry: successful test run mutes previous test failure — if enabled, TeamCity will mute a test if it fails and then succeeds within the same build. Such tests will not affect the build status. This is convenient for configurations with flaky tests that alternately fail and succeed when applied to the same source revision.
if an error message is logged by build runner: Mark the build as failed if the build runner reports an error while building.
if an out-of-memory problem or crash is detected (Java only): Mark the build as failed if a crash of the JVM is detected, or Java has out of memory problems. If possible, TeamCity will upload crash logs and memory dumps as artifacts for such 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:
tip
You can disable a build failure condition temporarily or permanently at any time, even if it is inherited from a build configuration template.
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:
A build metric exceeds or is less than the specified constant value (threshold).
For example, Fail build if its "build duration (secs) ", compared to the constant value, is "more" than "300 ".
In this case, a build will fail if it runs more than 300 seconds.A build metric has changed comparing to a specific build by a specified value.
For example, Fail build if its "build duration (secs)" compared to a value from another build is "more" by at least "300" default units for this metric than the value in the "Last successful build ".
In this case, a build will fail if it runs 300 seconds longer than the last successful build. If a branch specification is configured, the following logic is applied.
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
.teamcitydirectorybuild 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
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.
When using Regex, you can refer to the regular expression or its parts from the "Failure message" field (for example, refer to specific capturing groups with $N where N is the group number). This allows including the matching error text into the failure message displayed in the build results.
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.