I am running v2.6.3, and the retention policy for the lifecycle that my project is user is set to releases: 1 day and files: 1 day.
however, I am having several problems:
on any server’s, the folder c:\Octopus\Applications.Tentacle\Packages is not getting cleaned. it is just collecting .nuget files for all time. Retention policy is not being applied
on the same server, in the folder c:\Octopus\Applications\Environment1\Package1, there are many folders for both the current and previous versions of this package (many folders are named as the version plus underscore plus a number, e.g. 1.0.0_20 ). It does not appear to be applying the retention policy in this folder.
on the same server, in the folder c:\Octopus\Applications\Environment1\PackageX, where PackageX is a package that used to be deployed as part of this project, but is no longer, many old folders are still sitting here. Retention policy is not being applied.
problem #1 is the main one, using up the most disk space, but problem 2 is happening for multiple packages, and so it’s also a significant contributor to using up disk space.
thanks for any help. let me know if you need and screen shots or log files.
Thanks for reaching out. Could you please send us one of your deployment raw logs so we can check what might be going on?
looking at the raw log, it shows that it is deleting files, but here is the folder…
here’s a more complete list of what is being left behind in the c:\Octopus\Applications.Tentacle/Packages folder. note the numerous files with today’s date (March 3, 2015). (There are multiple deployments to the same box due to multiple tennants, so there’s lots of files repeating, but going to different places when deployed.)
octofiles.txt (212 KB)
I have a similar experience and are interested in how to make this work.
Thanks for all the info. Is it possible that you installed the tentacle twice on this machine or that you renamed the deployment steps?
Could you please send us a copy of your deploymentjournal file? on a default install it should be on C:\Octopus\Applications[tentaclename]\DeploymentJournal.xml
we actually have 8 tentacles installed on this server, the default tentacle, and an additional one using a different port for each tenant. however, due to firewall issues, we are only using the default tentacle. (almost all other servers in the enterprise also have multiple tentacles installed which are being used.)
renaming the step? the deployment project is still in development, so I’m sure steps have been renamed multiple times.
DeploymentJournal.xml (375 KB)
Sorry for the delay on my answer. DeploymentJournal.xml is the file that we use to track the files/paths to be deleted by the retention policies. Looking at the dates on your DeploymentJournal, I noticed that they jump from 2015-01-14 to 2015-02-25 to 2015-03-05. There are not records mentioning the files seen on your screenshot. For troubleshooting purposes i believe the easiest would be for you to manually delete the unwanted files just for this time, and then do a daily check for a couple of days to see if the retention policy is working or not. I realize this is a rather annoying thing to do, and trust me i’m not happy proposing it either, but i believe it will be the best approach which at the same time will free up some space automatically.
I’ll be waiting for an update from you. Thanks
I can do that for now on our 3 QA servers, but we have over a hundred servers in our staging, demo, and production environments, and deleting files by hand is not a viable solution.
I’m having the same problem with octopus 18.104.22.1686.
It isn’t cleaning up the files under Octopus\Applications[environment], or Octopus\Applications.Tentacle\Packages.
here are some updated files. normally, there are 9 deployments to the QA servers in the early morning (same packages, but deploying to different folders for 9 tenants). since its QA, there were a couple other deployments on 3/12 as well.
2 days in, it’s looking like it’s working as expected. I’ll check it again on Monday, when there will have been 3 more days of deployments.
ServerTasks-16508.log.txt (117 KB)
DeploymentJournal.xml (43 KB)
files.txt (3 KB)
Just a quick follow up - Is it still working as expected?
only if NOT deleting files is what we are expecting…
ServerTasks-16808.log.txt (119 KB)
DeploymentJournal.xml (37 KB)
files.txt (39 KB)
is there any documentation I can find (or you can send me) that describes what files are in the folders in the c:\octopus folder on a server, particularly when there is more than one tentacles installed on the server? I could use that to identify which folders are just holding old files, and I could develop my own script to clean it out.
so many files piling up is becoming a recurring problem on our servers, and it needs to be solved in a systematic way. If octo can’t manage it, I’ll have to develop a work-around.
The issue here is that the retention policies are actually applying (you can see this in the logs). However, since you have multiple environments on the machine, they just aren’t applying as much as you expect. Let me give an example.
Suppose you have one machine, that belongs to Dev, Test, Staging, and Production environments.
If you retention policy says “keep the last three deployments”, we’re going to keep 3 dev deployments, 3 test deployments, 3 staging and 3 production deployments. We will also only apply policies on a per-environment basis - for example, during a Production deployment, we’ll only try and clean up packages deployed to the Production environment - we won’t go and clean up dev and test deployments. In your deployment log, you can see files being deleted, but you also have some other files left over that you probably expected to be included in the same retention policy and therefore deleted. However, those are probably for different environments/steps, and so they won’t be. If you wanted the Dev or Test packages/files to be deleted, you’d have to do a fresh Dev or Test deployment.
C:\Octopus\Applications\.Tentacle\Packages is where NuGet packages get uploaded to. It’s safe to delete these whenever you like as long as it isn’t in the middle of a deployment.
C:\Octopus\Applications\<env>\<id>\<version> is where NuGet packages are extracted to during a deployment. You’ll have to be more careful about deleting these to make sure you aren’t deleting the ‘current’ deployments.
Hope this helps,
doesn’t help much. we use multiple environment to handle our multiple tenants, and many of our servers are shared by several tenants, so one server may actually be serving 10 tenants, and multiple packages get uploaded to that server for each deployment, so that’s a LOT of files, eating up a lot of space that just doesn’t seems to get cleaned up.
when cleaning out the c:\octopus folder manually, I often see files that are weeks or even months old. even with the retention policy behaving as you describe, these files should have been cleaned out a long time ago. I still suggest that there is a problem to be addressed here.
thanks for your help, though.
We are also having this same issue, though we only have a single tentacle on our machines. From what I can tell, the packages being left behind in our case are all from projects which have been deleted.
If I set the retention policy to Releases: 0 releases and Files: 0 releases, will it remove all files that were used during the course of the deployment?
if not, could that be added as an option?
I am noticing the same issue. There are many NuGet packages in my tentacle’s
C:\Octopus\Applications\Development directory, each of which have many old extracted packages (folders are named after the NuGet package version number) inside them. I’ve been manually deleting these version folders in the meantime.
The host machine has only one tentacle and I have only one environment configured in Octopus Deploy; my situation has nothing to do with multiple tentacles or environments. I’m using a basic “last three releases” policy.
I should also mention that I have Octopus Deploy configured to have the tentacles download the packages directly, rather than the server distribute the packages to the tentacle.