I dad a team today unable to create a release as Octopus was trying to get the latest NuGet package version but timed out. Using other tools, the NuGet server was fine but had a large number of packages in the feed (approx 340 total nupkgs). When we manually added the version number, the Octopus server had no problem saving and deploy the release. After the release was deployed, I was able to create another release and Octopus was able to find the latest version.
So what’s going on exactly? Does Octopus have a limit in terms of how many packages can a feed hold or is this a limitation with the NuGet server and how it interacts with Octopus for obtaining the latest package?
Thanks for getting in touch! Did you get a specific error? It is very possible that it is related to this issue:
Currently the only workaround is to restart the Octopus service when this happens.
If it happens again a stack trace would help to determine if it is related.
I got a NuGet timeout error. I wish I had taken a screenshot or written down the error number. So when the create release page initially loads and checks the feed for the latest versions, the error message says the feed had timed out and the initial versions are not populated.
In turn what this causes is any team using the octo.exe is unable to create a release after the build. We love our continuous deployment and want to make sure it’s not a problem in the future. If there’s a limit as to how many NuGet packages Octopus can scan a feed at a time, it would be good to know, or if this is a limitation of the NuGet server. If I run into this again, what should I record exactly?
Sorry just to clarify. Is it still happening or only happen that once?
I will get back to you with answers to your questions, I just want to clarify this first.
Sorry for not following up. We’re no longer running into this issue but it appears it may be a problem our nuget server, not Octopus per se. More research is being done but I’ll make sure to post our findings.
Our NuGet server (running version 2.6 on IIS 7.5) works just fine. When we run out of storage and clear some room, that’s when the trouble begins - timeouts and the like. We’ve noticed that Octopus seems to be a little sensitive to our NuGet server’s availability. To counter this we restart IIS and everything is okay, however we also have to restart Octopus Server Service as well. It’s strange, but it works correctly when both servers are restarted.
We’ve also figured out that packages that don’t fully upload or are 0k in length will render the feed to respond with an HTTP 500 error - which makes sense as the feed is likely scanning all the packages and returning a status code and response based on the scan of the packages. Just delete the bad packages and the feed is happy afterwards. Either way, we’re managing it now - we just had to learn the hard way.
