Re-deployment isn't using Tentacle package cache

(Chris) #1

Hi there,

I’m having trouble with re-deployment of packages and I could not find clear information on how it is supposed to work:

Octopus 2019.6.8. LTS


  • a package from an external NuGet feed is no longer present on the feed (for reference: FesadEssenceTransferService release 3.0.17)
  • the version was deployed successfully earlier this year
  • the retention policy of the lifecycle is at least 10 releases (no date!) and I can see the package in question in the tentacles cache of the server I want to deploy to (also in the correct environment folder):
  • during redeployment Octopus states it is checking the cache but then tries to download the package from the feed, which fails.



I was under the assumption that Octopus would use a locally cached package in the tentacle cache and only download a package when it is not available in the cache. Especially with this deployment option:

Any ideas why this isn’t working? Can we force Ocotpus to prefer the tentacle cache over (re)downloading?

Edit: The more I am reading the more I suspect that the behavior I am looking for is not implemented. Can you give suggestions what we can do to avoid losing packages from ext. feeds that are currently installed?

Thanks for any hints,

(Paul Calvert) #3

Hi Chris,

Thanks for getting in touch. There are two download and cache steps taking place during a deployment. First, the Octopus Server will connect to the NuGet feed and download the package to the Octopus Server cache folder. Then, during deployment, this package will be downloaded to the Tentacle cache folder. At each of these steps, Octopus will check to see if the package already exists in the cache folder before downloading and skip it if it is found.

The situation you’re in sounds like the package exists in the Tentacle cache but is missing from the Octopus Server cache, which is causing it to attempt to download from the feed. This download is necessary so that the server can compare the package against what is located in the Tentacle cache to confirm whether replacement is required.

The Octopus Server will only retain cached packages for 20 days by default.
This value can be increased using the command line tool. However, I’m not sure if that would be a long term solution for you as there is no way to configure it only to keep packages attached to a release.

Another option would be to alter how your build pipeline works and have production builds pushed to the built-in Octopus repository where the retention policy will only remove packages that are not attached to a release. I do realise that this isn’t likely to be a small piece of work for you but may offer the best all-round result.

A final option would be to amend how your external repository retention policy works, possibly adding some logic that queries the Octopus API to check what packages are in use and skip deletion of them.

Not sure if any of these options are going to help you in the short term, but hopefully it provides some useful direction for you.

Let me know if you have any further questions.

Best regards,

1 Like
(Chris) #4

Hi Paul,

thank you for your detailed response, this cleared up my false assumptions.
Since we are also deploying packages from external NuGet feeds that cannot directly access our Octopus instance, using the internal feed isn’t really an option.

After a bit of discussion we are opting for increasing the server’s cache to 365 days. We are not deploying so many different products that this should be a space or quantity issue, but I guess we will find out :-).

Are there any plans to also link the server cache with retention policies that are tied to current releases? I guess this would be a nice feature, because I think it is not necessarily ideal that for getting proper retention you have to maintain a NuGet feed and also push directly to Octopus.

In any case thanks for your input, much appreciated.
Enjoy the weekend,

(Paul Calvert) #5

Hi Chris,

Having spoken with our engineers regarding how retention is handled for external feeds, they have advised that there is currently no plan to expand the retention policy to include the server cache.

The view is that this scenario would be best handled at the external repository side. It is possible to query the Octopus API to retrieve a list of packages that are currently tied to a release; this list could then be excluded from any cleanup taking place in your external repository.
Example Script.

We do have a user voice page where you can raise this request though, and if it begins to gain additional support, then it would be reconsidered.

Best regards,

(Chris) #6

Hi Paul,

thank you for following up on this. We changed the package cache on the Octopus server to hold packages for longer. If this
doesn’t work out we will implement a logic in our external repository using the script example you provided.

Thanks and best,


1 Like