Configuring Retry Build Triggers
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.
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. |
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. |
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.