I’ve set up a few projects on OD 3.3.0 with custom install directories, but for some reason it’s deploying to both the custom directory and the default Octopus Application folder (i.e. C:\Octopus\Applications%ENV%). I’ve also noticed that some config transformations we being performed on the Octopus Application folder only so my deployments fail to work. This does affect multiple projects and environments too.
I’ve only ever had 3.1.16 and migrated to 3.3.0 so there’s nothing too legacy to worry about.
Im having the same problem, i select a custom install directory, all the files are installed but i get a bunch of folders within the install directory dev/appname/2.0.0.0/ and the files are installed in this location also (twice). I just need the files in the package saved to 1 folder only without this folder structure? pls help!
That said, the fact that files are being transformed on the application directory but you are not seeing those changes on the final custom dir does sound like a big problem. Could you please follow the below steps to provide me with a verbose deployment log so I can see what is going on?
Create a new release (so the new variables take effect) and deploy it. If possible skip as many steps as you can and only leave step we are troubleshooting in order to avoid the noise in the log.
Please read the first couple of lines of my reply above where I explain the reason behind the code duplication.
Adding to that - When the deployment finishes, do you get the code that you want on the desired directory, despite the mentioned duplicates? This is the most important thing on the deployment and I want to make sure that is working as expected.
Will try this when back in work as just been on holiday
It really came to my attention as the deployments piled up and filled the system drive with ~30Gb of installs (~500Mb each install), so I’ll be checking retention policies too first thing!
Thanks for the help and I’ll be back in touch when I’ve done the above steps
I have the same situation and I have read the explanation provided in the post of dalmirco. But my custom directory is also using a package version as well, so I have never the situation of deploying to an existing directory.
So could this be turned off? I want to have my webserver clean of crap.
To answer your last question, this cannot be turned off if you are using the Custom Installation Directory feature.
If your custom directory is already using the package version (C:\Custom\{version}), why not use the Octopus default package instead(C:\Octopus\Applications\{Project}\{Package}\{version}), and reconfigure your service/webapp point to that new path on each deployment? This way you wouldn’t have these duplicate files and you’ll take full advantage of the cleanup capabilities of the Retention Policies. Octopus already has a variable called #{Octopus.Action[StepName].Package.CustomInstallationDirectory} which will automatically hold the exact path where your app was dropped on each deployment. So you’ll only need to reconfigure your Service/App to point to that path using that variable.
Though the Custom Installation Directory is a handy feature, we try to recommend users to avoid it if possible. Not because its bad, but because Octopus already provides an automatic path structure based on Project/Environment/ReleaseVersion and tools for you to reconfigure your service/app to point to that path.
I came to the same conclusion. The reason why I had the custom directory was to group certain packages together. Mostly because they share the same config. But in the end I figured that it was easier to manage this in octopus and I got rid of the custom directory.
Thanks for your input I helped me to confirm my conclusion.
