Configuring Finish Build Trigger

Triggering Settings

In most of the cases, the finish build trigger should be used with snapshot dependencies, that is the current build configuration where the trigger is defined should have a direct or an indirect snapshot dependency on the build configuration selected in the trigger. If there is no snapshot dependency, the following limitations exist:

• It is likely that a build of the build configuration being triggered will not have the same revisions as the finished build even if both configurations have the same VCS settings.

• If a build configuration with the finish build trigger has an artifact dependency on the last finished build of the build configuration specified in the trigger settings, there is no guarantee that artifacts of a build which caused build triggering will be used, because, while the triggered build sits in the build queue, another build may finish.

• The build triggered by the finish build trigger will always be triggered in the default branch even if the finished build uses another branch.

• The algorithm does not guarantee that every finished build in a monitored configuration will trigger a respective build in a configuration with the finish build trigger. In certain cases, for example, if two monitored builds finish somewhat simultaneously, only one respective build might be triggered. For more details on this limitation and its possible workarounds, see the related task in our issue tracker; if this limitation restrains your build pipeline anyhow, please leave a comment to this issue describing your use case.

All these limitations do not apply if a build configuration with the finish build trigger has a snapshot dependency on the selected build configuration. In this case, the trigger will run build on the same revisions and will attach the build to the chain. It will also use consistent artifacts if they are produced by dependencies.

Note that if a build configuration with the finish build trigger has a snapshot dependency on the selected build configuration, the trigger will be able to detect if the last monitored build has already been promoted to the current build configuration (either manually or by another trigger). In this case, the trigger will not run a new build.

In a build configuration with branches, you can use the branch filter to limit the branches in which finished builds will trigger new builds of the current configuration.

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.

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.