We use tenants to help us manage the deployment of git topic branches. The creation and deletion of tenants in this case is highly dynamic and one of the challenges we are facing right now is the retention policies. The major problem is that as soon as a tenant is deleted, there is no more deployments for this tenant and as a consequence – no cleaning up of the deployment artifacts on tentacles.
Before jumping into the implementation of the custom solution, I would like to ask you, guys, if you have recommendations on how to deal with this problem.
Thanks for getting in touch! Currently Octopus will not cleanup anything on a Tentacle outside of deployment of a project. There is no uninstall or remove concept when we delete either tenants or projects.
However we do see the use of a feature like this, so one of the developers and myself had a bit of a brainstorm about what we could offer in this space for Tentacle cleanup.
We came up with the following idea: https://octopusdeploy.uservoice.com/forums/170787/suggestions/18644866
Please visit this suggestion on UserVoice and give it some votes and comments. We would really like to see some community support behind the idea as it has been asked for in the past.
Potentially in the mean time, as you do have information such as which Tenants you are deleting, you could write a project that connects to machines and looks for those tenants in the deployment journals to remove the files you are interested in.
If you want to go down this path I a sure we could assist with the logic we use.
In the meantime, we’ll implement our custom solution. The only uncertain thing for us is how to handle the deployment journal. Looks like we have to delete the deployment entries for deployments we are about to clean up. Is it as simple as just rewriting the existing journal without those entries or are there pitfalls?
Deleting them from the deployment journal would be optimal, and the only pitfalls that I would see would be if you changed the permissions so Octopus could not write or read from the file. If you run your script via Tentacle this will not be an issue.
The second is if you had the file open when it was needed by another process it may throw or error in that deployment/process.
Calamari is OSS and here are a few of the functions that are called for our retention policies:
Let me know if you run into any issues or if you have any questions.
Yes, we implemented the custom solution. In our case tenants are git topic branches and the deletion/cleaning procedure is triggered by a git server hook. In response to the topic branch deletion the hook creates a release of the dedicated Octopus project (we named it “git-topics-cleanup”) and adds deleted ref names as release notes. The deployment step in this project parses ref names and comes up with corresponding tenant names (we use jira ticket keys as part of tenant names). Then it queries the tenants and creates a list of projects and environments for each tenant. So far it is pretty straightforward.
Each project that is connected to those tenants has a dedicated channel (we call it “Branch Topic Cleanup”) and a dedicated cleanup step that executes only for this channel. “git-topics-cleanup” deployment step creates release for each project associated with those tenants and deploys it for “Branch Topic Cleanup” channel and corresponding environments. This way we guarantee that the cleanup step will run on all machines containing artifacts for the tenants.
Now, we do some extra work during this step which may not be interesting for you (like, removing web sites, databases, etc.) but here is the part that takes care of the deployment artifacts: