Nuget Build Triggering

Something really weird is happening with the Nuget Build Triggering.  It appears that Nuget Build Triggers never happen if the project where the trigger exists in the same project page as that of the project triggering the build.  For example, we have a libraries project page and a contracts project page.  When we build a core library, other projects within libraries are setup to build when the core library updates on nuget.  The projects in libraries never are triggered.  Using the same exact template for our projects in contracts, they all trigger when the core library updates.  The only way I can get the libraries to trigger is by setting up a nuget build trigger to reference something under contracts which is starting from a trigger within libraries.  Seems like an around the barn fix.  This is boggling my mind as they are all on the same template.

Any ideas?

12 comments
Comment actions Permalink

Hello,

What NuGet feed(s) do you use? Do you use TeamCity-provided NuGet feed?
If you use TeamCity provided NuGet feed, please make sure that created NuGet packages are guest-user accessible
(as TeamCity NuGet trigger will use TeamCity guest account to check the feed)

Please report server debug logs for us.
Take a look at the doc for details:
http://confluence.jetbrains.net/display/TCD7/Reporting+Issues

What NuGet version do you use in the build trigger?

0
Comment actions Permalink

We do not use TeamCity's NuGet feed since we do not have TeamCity 7.  We have setup our own feed.  Today I will get the logs for teamcity and post them up.  Thank You for the reply.

NuGet version is 1.6.

0
Comment actions Permalink

I did what you said and turned on debug-all mode then found the log that may have contained the data.  The problem is the logs generate 1000+ pages per 10 - 20 seconds with debug on.  It seems as if the debug logs are completly filled with nuget entries.  Does this ring any bells?  Log is too large to attach to this reply.

0
Comment actions Permalink

Hello,

I need just to figure out what went wrong. So if you see repeating errors, one error would be enough.
We may start with it.

0
Comment actions Permalink

This is what my logs look like after I kick off a build with debugging on.  I am not sure if you are going to be able to make much from this.  They are so large I only included a small amount of the log.



Attachment(s):
tcLog.txt.zip
0
Comment actions Permalink

In the logs you see messages like:

[2012-04-02 09:48:24,834]  DEBUG - ger.NamedPackagesUpdateChecker - Recieved packages hash:  ***
[2012-04-02 09:48:24,834]  DEBUG - ger.NamedPackagesUpdateChecker -           old hash was:  ****

the hash value is the string of all packages from the feed that were detected by the trigger. As the list changes build are started.
Please check you see new version of your library in the feed.

BTW. Do you use prerelease versions? Are those version listed in the hash?

0
Comment actions Permalink

I have checked our feed and our NuGet packages are updating.  For the example using Core, the version increments on our NuGet Feed.  (480 -> 481)  When this happens, it should be triggering a build on some of our other libraries, but nothing happens.  Our other libraries are only building on the schedule at night rather than the trigger we have setup.  The only problem is, TeamCity is not trigging other builds once a library is updated.  (This is intermittent for some of the libraries.  They all use the same template though.)

I have attached a screen shot of what one of the other libraries build triggering setup looks like.



Attachment(s):
BuildTriggering.jpg
0
Comment actions Permalink

I just updated our NuGet Plugin and now many of our builds are triggering properly.  The builds within the same Project Group / Name are still not triggering though.  I have attached a screen shot to show you the contract projects triggering off a build of our core library.  At this point, the only remaining problem is our other libraries are not triggering from the core library update when they should be.



Attachment(s):
BuildQueue.jpg
0
Comment actions Permalink

Please check what versions of library are detected in the logs in hash strings.

What are current versions of the library?

Do you use -prerelease versions?

What are NuGet trigger settings for the library? What NuGet version is used there?

0
Comment actions Permalink

We do not use pre-release versions.  What I can tell you is we are running NuGet 1.6 and the library triggers are setup using the same templates as the contract triggers.  Essentially there is no reason that if a contract NuGet trigger is activating why a library trigger shouldnt as well.  I can have the libraries trigger if I set them to trigger off contract triggers.  This is tough to explain the problem, but when I have Core update, only NuGet triggers activate if they are not part of that group (Library) which Core belongs to.

The work flow for me to get this to work looks like the following.

Update Core (Located in Libraries) -> NuGet Trigger in Contracts due to Core update -> NuGet Trigger in Libraries due to Contracts update

I would like to have the following, but this does not work:

Update Core (Located in Libraries) -> NuGet Trigger in Libraries due to Core update

0
Comment actions Permalink

Eugene,

I work with Adam and I am looking into our nuget triggering issue as well.

Yesterday I upgraded our TeamCity from version 6.5.3 to 7.0.2. In v6.5.3, the nuget triggering was spotty, but since I upgraded to v7.0.2, no builds have been triggered by a nuget package update. I have forced many updates on a variety of packages and nothing is getting triggered by nuget. v6.5.3 was running on Windows Server 2008 R2. v7.0.2 is running on Ubuntu Linux. (I am the one that submitted (http://youtrack.jetbrains.com/issue/TW-20945).

I turned on debugging logs and Nuget is quite chatty, so something is going on.

One of the nuget packages we are concerned with has the ID Chatham.Libraries.Core. This has been updated many, many times since September 2011 (easily several hundred times, maybe even 500+ times). I looked in the debug log and I see an entry like (this has been truncated significantly):

[2012-04-08 11:46:17,183]  DEBUG - ger.NamedPackagesUpdateChecker - Recieved packages hash: |s:http://nuget/api/v2/|p:Chatham.Libraries.Core|v:2011.1003.52.53640|s:http://nuget/api/v2/|p:Chatham.Libraries.Core|v:2011.1004.53.53911|s:http://nuget/api/v2/|p:Chatham.Libraries.Core|v:2011.1004.54.53918...


I did a quick cut and paste into a spreadsheet, and it looks like the nuget plugin stops after 100 entries, which I believe is the default chunk size from the Nuget atom feed. The order of the versions in th log match the version order listed in the nuget gallery. I'm not sure how it determined the version number to start the query, since it is neither 100 entries from the eraliest version (it is about 20 or so) or 100 entires from the latest. The latest version listed in the logs is 291 versions earlier than the latest in the feed.

I have a sneaking suspicion that the nuget trigger can't handle any packages IDs with more than 100 versions returned from the nuget feed. I'm going to try and cleanup the excessive versions to see if that helps. Unfortunately, the nuget gallery doesn't have an easy way to delete old unneeded packages, so it will take a while.

This issue is significant enough that I may be forced to rollback to v6.5.3 until it is resolved (v6.5.3 is intact on an idle server and database).

I have attached teamcity server logs.

Thanks for your help!



Attachment(s):
teamcity_server_logs_2012-04-08.zip
0
Comment actions Permalink

Thank you for detailed logs. Unfortunately, it's true that our Linix implementation of the trigger does not support OData feed paging.
I created an issue for that at
http://youtrack.jetbrains.com/issue/TW-21048
Please vote for it.

0

Please sign in to leave a comment.