TeamCity 7.0.2 NuGet trigger.


My scenario is that I have a library project which produces a NuGet package using TeamCity 7 to publish to the local TeamCity feed. When the library has built it seems to be taking 5/6 minutes before any dependant builds are triggered and I was hoping for it to be a bit quicker (one or two minutes). I have some questions around that and some general questions:

My questions are:

  1. How often does a NuGet package trigger check for updated packages?
  2. Is there any way of changing it in a similar way to the VCS trigger?
  3. Is there any way of having different trigger times for different NuGet servers. For instance I may want my local packages to trigger quicker than a package from the offical NuGet package source as local packages are really just the same as chained builds.
  4. Is there an alternative way to trigger one build on completion of another without copying artifacts? If so, how do I do that and do you recommend it over the NuGet trigger?
  5. Given that an all-local NuGet dependency is really just another type of build dependency should/could they be included in the dependency graph?
  6. After a package has been updated it would be useful to update the VCS repostory (Git in my case) of the depenant project to reflect this, is this possible? Without doing this developers may be building and testing against an old version of the package whilst the one being deployed via teamcity is different. Additionally if they do notice they need a newer version of the package and update it and check it in then we will end up doing a second unecessary build.
  7. Continuing from question 6 (sorry about this), if a user with an old version of a package checks a change in to VCS which triggers a build, will the build use the old version of the package from source control or the latest version from the package server? Do I need to include a NuGet Installer step?

Finally a small suggestion; when setting up a trigger it would be useful to not have to enter the url for the NuGet Package source for local TeamCity feeds as presumably TeamCity already knows where they are. Don't worry, I've just found the %teamcity.nuget.feed.server% variable.


Comment actions Permalink

I tried using %teamcity.nuget.feed.server% in the trigger but I get:

"Failed to check for package versions. Failed to execute NuGet TeamCity.ListPackages command. Exited code was 1"

Stack Trace:

jetbrains.buildServer.buildTriggers.BuildTriggerException: Failed to  check for package versions. Failed to execute NuGet  TeamCity.ListPackages command. Exited code was 1
at jetbrains.buildServer.nuget.server.trigger.NamedPackagesUpdateChecker.checkChanges(
at jetbrains.buildServer.nuget.server.trigger.NuGetSimpleTrigger$1.triggerBuild(
at jetbrains.buildServer.serverSide.impl.BuildTriggersChecker.triggerBuilds(
at jetbrains.buildServer.serverSide.impl.BuildServerRunner$4.doSomething(
at jetbrains.buildServer.serverSide.impl.BuildServerRunner$
at Source)

Comment actions Permalink

Thank you. Please vote for TW-21103

Comment actions Permalink

Thanks Eugene, actually I created that bug report! :^O

Any thoughts on my other questions? Sorry I know there's a lot!

Comment actions Permalink

I think these are awesome, well thought out questions, and I hope they are considered for future TeamCity releases.

Comment actions Permalink

The fix for the issue is available in TeamCity 7.0.3.

Comment actions Permalink

Yes, the fix for using the nuget path variable is in 7.0.3. The seven items above that are questions about / possible enhancements to the usability of nuget in TeamCity.

Comment actions Permalink

There are great questions! If you have gained any insights on questions 5-7 I'd be very interested!

Comment actions Permalink


Thank you for questioning this once more. I'll try to answer all those question here

NuGet packages are checked from several threads (4 by default or 'teamcity.nuget.trigger.pool' internal property.
Each thread is calling a check request for a number of packages at once (10 by default or 'teamcity.nuget.trigger.bulkMode.maxPackagesToQuery' internal property).

Yes. See internal properties for 1.

Not yet. Please create an issue

This is of course possible. Out NuGet support does not provide out of the box support of it. You may consider sharing some files between builds under wellknown directories. It is also possible to specify 'Run on the same agent' option in builds snapshot dependencies configuration. If you have good scenario to consider, please create another issue/post

It should be, but this is not yet implemented. Please create an issue for that.

TeamCity does not provide any auto-commits out of the box. You may call custom commit/push commands in a build step of a build configuration. To run VCS commands on checkout directory you need to use agent-side checkout. Please note that auto-commit may re-trigger build.

NuGet installer step assumes you need to re-install packages. Any way it calls NuGet install command for all packages files. It's up to NuGet.exe to decide weather it should update existing package or leave it untouched. I believe it's always better to avoid any packages being checked in to version control

Hope this answers questions :)


Please sign in to leave a comment.