Deploy using API goes into timeout and doesn't create a release

Legacy Uncategorised
1

Actually we are facing an issue with one of our applications. The Nuget package is 200Mb and it takes a while to be downloaded from our internal Nuget repository.
We are using the following command to publish over Octopus:
`
create-release --project=“xxx” --version=“2014.1.80” --deployto=“Staging” --server=“http://xxx:8383/” --apiKey=“API-xxx” --releasenotesfile=“xxxReleaseNotes.txt” --waitfordeployment

Executing ‘xxx\OctoPack\Octo.exe’ create-release --project=“xxx” --version=“2014.1.80” --deployto=“Staging” --server=“http://xxx:8383/” --apiKey=“API-xxx” --releasenotesfile=“xxxReleaseNotes.txt” --waitfordeployment

And this is the console output

Process INFO: Octopus Deploy Command Line Tool, version 2.0.12.32
Process INFO: Handshaking with Octopus server: http://xxx:8383/
Process INFO: Handshake successful. Octopus version: 2.3.3.1369; API version: 3.0.0
Process INFO: Finding project: xxx
Process INFO: Finding deployment process for project: xxx
Process INFO: Finding release template…
Process INFO: Resolving NuGet package versions…
Process INFO: Finding latest NuGet package for step: Deploy Setup
`

If I check the tentacle log nothing is mentioned about the release failure, but the release is not there, if I create a new one manually it works. Our Nuget repository is very slow at the moment so I am wondering if Octo.exe has a sort of timeout in place?

2

It looks like that Nuget internal repository doesn’t work well at all when you are working with a Network drive to host your packages, which sounds quite obvious to me when you have an ALM ecosystem in place.

Anyway, I got my Nuget repository back to normal performances and Octopus start back to deploy properly my Applications.

Two things here:

  • Nuget doesn’t work over a mapped network drive and I found also this https://nuget.codeplex.com/discussions/247463
  • Octopus API deployment goes into timeout quite fast, we should be able to control that or re-try multiple time to query the package repository until we get the correct response message

My two cents

3

Thanks for the follow-up. Have you looked into the built-in package repository in Octopus 2.1+? Rather than map a feed to a Windows file share, the built-in repository uses a fast package index (courtesy of NuGet.Lucene) that will likely perform much better in your scenario.

The built-in repository does however require local disk storage on the Octopus server, so that may rule it out.

Hope this helps, anyway.
Nick

4

Thanks for the tip Nick, I wasn’t aware of this new functionality yet, I will probably have a look today and test it cause it makes a huge difference for us cause the actual Nuget repository is slow even on an SSD local disk, probably because we have now thousands of packages and they are quite heavy in size. It seems that Nuget scan the folder each time instead of having a sort of cached list of available packages