Octopus and TeamCity NuGet feed - 400 Bad Request

reliability
external
#1

Hi,

We have always used TeamCity NuGet feed to source our packages in Octopus. Recently we migrated our TeamCity instance to a new server.

When we try to deploy we get the following:

The step failed: Activity failed with error 'The package [PACKAGE] v1.0.0.2705-256 could not be downloaded to the package cache from NuGet feed ‘TeamCity Feed’ after making 5 attempts over a total of 104s. Make sure the package is pushed to the feed and try the deployment again. For a detailed troubleshooting guide go to http://g.octopushq.com/TroubleshootMissingPackages

System.Exception: Unable to download package [PACKAGE] v1.0.0.2705-256 from NuGet feed ‘TeamCity Feed’: Error downloading .1.0.0.2705-256 from http://[OUR TEAMCITY SERVER]:443/httpAuth/app/nuget/feed/_Root/default/download/[PROJECT]/43868:id/nupkgs/[PATH]/[PACKAGE].1.0.0.2705-256.nupkg —> System.Exception: Error downloading [PACKAGE].1.0.0.2705-256 from http://[OUR TEAMCITY SERVER]:443/httpAuth/app/nuget/feed/_Root/default/download/[PROJECT]/43868:id/nupkgs/[PATH]/[PACKAGE].1.0.0.2705-256.nupkg —> System.Net.Http.HttpRequestException: Response status code does not indicate success: 400 (Bad Request).

Now, the interesting bit above is that it shows “http://” but specifies port :443 which would cause the 400 bad request.

If I use the link in the error message above directly and we are authenticated with our TeamCity server, we can download the package.

In the External Feeds we specify:

https://[OUR TEAMCITY SERVER]/httpAuth/app/nuget/feed/_Root/default/v2

Where we use “https://” - we have also tried “http://” and supplying the ports in the URL as well, nothing fixes this issue.

If we use the “Test” function, then packages can be searched for, and the correct versions shown.

We have tried deleting the feeds and creating new ones, and this still doesn’t resolve this error.

Any pointers would be great as this is blocking us at the moment.

Kind regards,

Mike

#3

I’ve just realised there is a configuration difference between our old and new TeamCity server - the old was on an Windows box, and the new is Ubuntu and fronted with nginx - I wonder if that could be causing the difference in behaviour.

Either way however, the External Feeds -> Feed -> Test works fine, so I cannot understand why a deployment cannot consume it?

(Dalmiro Grañas) #4

Hi @mgoodfellow,

Thanks for reaching out! When you use the Feed -> Test feature, the request comes from the Octopus Server to the package feed. Is there any chance your deployment is configured so each target/tentacle downloads the package directly from the feed instead of doing it through the Octopus Server? In that case the requests would come from the Targets/Tentacles, and that might give you some ammo to investigate the network connection between them and your package feed.

While you investigate that, I’m gonna bring this up to the team to see if they have more ideas about your issue.

Regards,
Dalmiro

(Dalmiro Grañas) #5

  • Is this happening to every single package you download from that feed?

  • How big are your packages? Perhaps your new nginx’d TC server is not allowing Octopus to downloads packages bigger than X?

  • Have you tried checking your Nginx logs to see if they have more clues about why these downloads are being cut?

#6

Thanks for reply!

Is there any chance your deployment is configured so each target/tentacle downloads the package directly from the feed instead of doing it through the Octopus Server ?

I’ve tried both methods

Is this happening to every single package you download from that feed?

Yup

How big are your packages? Perhaps your new nginx’d TC server is not allowing Octopus to downloads packages bigger than X?

About 30mb - I can hit the URL in my browser and download the package to my local machine - should be exactly the same HTTP request

Have you tried checking your Nginx logs to see if they have more clues about why these downloads are being cut?

It never hits the nginx access or error logs strangely when doing the deploy - I think its due to the malformed URL? (http:// and :433 in the URL)

When I fire off the test search I get it in the nginx logs:

“GET /httpAuth/app/nuget/feed/_Root/default/v2 HTTP/1.1” 200 354 “-” “NuGet Client V3/3.6.0-octopus-58694 (Microsoft Windows NT 10.0.14393.0)”

Kind regards,

Mike

(Dalmiro Grañas) #7

Hi @mgoodfellow,

Thanks for taking the time to answer all those questions! I’m gonna bring this up to the team to see if they got ideas about your issue. In the meantime, could you help me with the below questions?

  • So If I understood correctly, you are setting up the feed as https://[url], but from the deployment you see it being used as http://[url]:443?

  • Which version of Octopus are you running?

  • Could you go to Library -> External Feeds -> [your feed] and from the browser’s development tools send us the JSON response of the call that was made to /feeds/feeds-[your feed] ? If that response contains sensitive data, feel free to send it over to support@Octopus.com

Thanks,
Dalmiro

#8

you are setting up the feed as https://[url] , but from the deployment you see it being used as http://[url]:443 ?

Exactly

Which version of Octopus are you running?

2019.11.3 (cloud instance)

If that response contains sensitive data, feel free to send it over to support@Octopus.com

Emailing now, thanks!

Mike

1 Like