Change in where nupkg files are stored

Just wanted to bring up that there is another backwards incompatible change in 3.0 that has affected us, but its also because we do weird things ;). So in octo 2.0 you stored the raw nupkg files in the Applications directory under

<applications dir>\.tentacle\<feed>\<package>

In octo 3.0 this has switched to now be under

<tentacle dir>\File\<feed>\<package>

Because of the lack of retention policies on how long these packages are stored and the fact that every deploy for us is ~2gb of compressed packages we have to manually apply retention policies on the packages to help with space concerns. I doubt that this is very much a concern for other clients but just wanted to bring attention to it.

I also wanted to know if there were any plans to allow retention policies on downloaded packages on tentacles (currently the previous unpacked folders are in retention policies but the nupkg files are not cleaned up for a month which is excessive!

Thanks,

Hi Brent,

Thanks for reaching out. Retention Policies on Tentacles do delete packages. Here’s an extract from our documentation:

The Tentacle settings delete packages, and expanded files and folders from packages on the Tentacle machine that is being deployed to. Note that if you use the Custom Installation Directory feature, we will never delete from that directory during retention policies. This can be purged during deployment in the project step settings. But it is assumed this will have a working release in it.

Also, the paths you mention don’t match the 3.0 structure. How weird are the things you are doing exactly?

Could you also share us the deploymentjournal.xml of one of the Tentacles where you are seeing that the files are not being deleted? The file should be on the root of the Tentacle dir.

Thanks,

Dalmiro

Let me see if Octo 3.0 deletes the packages. The last time we checked this it was in 2.X because the actual nupkg files were not being removed from what we saw. We also didn’t like that the retention policies wouldn’t run for packages if the deployment failed which for small projects that is fine but for our use case we always want to clean up packages because of the space concerns. Is there a way to force retention policies on failure by chance?

The fact that they get triggered only during successful deployments is as design. There is no way to force them to run on failure.