NuGet Dependency Trigger

Requirements and limitations

For a TeamCity server running on Windows, .NET 4.0 is required.

For a TeamCity server running on Linux, the NuGet dependency trigger will reportedly work with the following limitations:

• filtering by Package Version Spec is not supported

• only HTTP package sources are supported

• NuGet feed version 1.0 is used, so case-sensitivity issues might occur

• the current trigger implementation on Linux might increase the server load

• authentication issues might occur

Triggering Settings

1. Select the NuGet version to use from the NuGet.exe drop-down menu.

   tip

   The recommended approach is to preinstall NuGet via Administration | Tools. In this case, the installed version will automatically appear in this menu. If you want to provide a custom path to a NuGet executable, you need to explicitly allow its usage on the server by specifying the following internal property: Plain Text teamcity.nuget.server.cli.path.whitelist=<disk>:\\<path-to-executable>\\NuGet.exe

2. Specify the NuGet package source, if it is different from nuget.org.

3. Specify the credentials to access NuGet feed if required.

4. Enter the package ID to check for updates.

5. Optionally, you can specify package version range to check for. If not specified, TeamCity will check for latest version.

You can also opt to trigger build if pre-release package version is detected by selecting corresponding checkbox. Note that this is only supported for NuGet version 1.8 or newer.

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.