I setup Octopus for the first time to try how it works. So far I installed the Octopus server, the tentacle and configured NuGet as a local feed. I published a package using OctoPack, created a release and I’m trying to deploy it to staging.
On the first step I get an error The package could not be downloaded from NuGet.
ERROR Unable to download package: Could not find package Web 1.0.0.0 in feed: ‘\solomon\deednugetfeed’ System.Exception: Could not find package Web 1.0.0.0 in feed: ‘\solomon\deednugetfeed’
Well, the package is there, the NuGet repository test succeeds.
The portal, Octopus service and the NuGet feed are running on Win2008 machine. At first the Octopus server was using the default Local System account, the portal the default ApplicationPoolIdentity (the portal has its own pool). While trying to deploy I got the error listed above. Then, I created a new local account, added it to the Administrators group and set both the octopus service and the app pool to run using the new account. The NuGet folder is shared with the new account. Unfortunately that didn’t have any effect (all services are restarted).
To make sure I understand, you’ve created a new account, made the Octopus service run under that account, and granted that account access to the NuGet file share - and yet you are getting the download error during deployment?
Do you get a similar error when you search the NuGet repository using Configuration -> Feeds -> Test? Or when creating a release? Or is it just during deployment? If so, I would say there must still be a permissions issue preventing the account that the Octopus windows service runs as from accessing the file share.
You got the problem right. It works fine when I test the feed (from Config -> Feeds -> Test). I get the error only upon deployment. I rechecked the file share and the account the service runs on. I attach a screen shot from the File Sharing and the Octopus service dialogs (the user is named octopus).
To test the account I also tried to map the file share using the octopus account and it worked just fine. So obviously the user has access to the file share.
Since I couldn’t resolve the issue with a local feed, I decided to try with a remote NuGet feed. I configured it to run on http://emil:81. I can successfully access it from the server Octopus is installed on. However, when I try to test the feed from the Octopus portal I get:
There was a problem processing your request: 400 Could not connect to the feed specified at ‘http://emil:81/’. Please verify that the package source …
Guys there is seriously something wrong with the way Octopus handles the NuGet feeds. The error handling also seems to be poor. How can the test on the local feed succeed, but then on release it fails to download the package?
Also the support I get here on this forum is quite unsatisfying in terms of timed responses.
I got this problem but figured out what was wrong. When Octopus is installed it installs two things on the server and one on the agent. On the server the web application is installed as well as the Octopus service, and on the agent a tentacle is installed.
My problem was that everything looked fine when I was testing it from the web, but it seems like since the service were running under different credentials compared to the application pool it couldn’t access the feed. Also, specifying credentials for the nuget feed didn’t seem to help either, but changing the user for the service seemed to have helped me.
