TeamCity On-Premises
 
2023.11
Get TeamCity On-Premises
  1. Managing Build Configurations
  2. Creating and Editing Build Configurations
  3. Configuring Build Triggers
  4. Configuring Retry Build Triggers

Configuring Retry Build Triggers

Edit page Last modified: 14 December 2023

The retry build trigger automatically adds a new build to the queue if the previous build of the current build configuration has failed.

note

To configure the retry build trigger in Kotlin DSL, see RetryBuildTrigger.

Triggering Settings

The following settings are available for the retry build trigger:

Setting

Description

Seconds to wait

Specify seconds to wait before adding a new build to the queue.

Number of attempts to retry the build

Specify how many times the trigger will try to rerun the failing build. Leave blank to retry unlimited times until the build is successful.

Trigger a new build with the same revisions

With this option enabled, the retry trigger will rerun a failed build using the same source revisions.

This option helps identify build problems that do not depend on the build code: for example, if there are flaky tests in the build configuration or if there was some unforeseen agent compatibility issue.
If the build with the trigger is a part of a build chain, all the successful builds from the previous chain run will be reused and all the failed dependency builds, that could have contributed to the failure of the dependent build, will be rebuilt on the same revision.
If any build parameters or comments are specified in the custom build settings, they will be applied to the following build runs initiated by the retry trigger.

Put the newly triggered builds to the queue top

With this option enabled, retried builds will always be put to the queue top.

Branch filter

Apply a branch filter to rerun failed builds only in branches that match the specified criteria.

Triggered Build Customization

The Build Customization tab of a trigger's settings allows configuring custom parameters of builds started by this trigger. Similarly to the Run Custom Build dialog, it lets you override values of build parameters and choose if the checkout directory should be cleaned before the build.

On this tab, you can customize the value of any parameter used in the current build configuration. Or, you can add a new parameter, and it will be available only in builds started by this trigger. If the current build has snapshot dependencies on other builds, such a parameter can also be used to override a certain property of a dependency build configuration: use the reverse.dep.<dependencyBuildID>.<property> syntax for this.

tip

This functionality gets more effective if you combine it with the build step execution conditions. You just need to add a parameter-based condition to a step and then configure two triggers: one will run builds with this step (when the condition is satisfied) and one — without it. A popular use case is to run a limited number of tests in regular builds but a full set of tests in a nightly build, when the server load is the lowest.

Note that if you redefine a build parameter inside a trigger and then delete the original parameter in Parameters, its redefined value will be converted to the trigger's own plain-text parameter. This is crucial to consider when customizing secure values, as they are only concealed if stored with the "Password" type and will become readable if converted to plain text.

TeamCity allows solving similar tasks in multiple ways, and in some cases it is still preferable to create different build configurations. For example, if there are too many custom runs in the same configuration, it might be harder for TeamCity to predict the exact duration of each build. If you need to trigger builds with numerous different parameters, we suggest that you create a build configuration template and use it as a blueprint for several configurations, each with its own parameters.