Hi,
We are upgrading our Octopus from 2018.8 to 2020.3. We would like to know if there are any old data in the database that we can purge before we do the upgrade.
We have the retention policy set but we would like to verify if the purging is working as expected.
Thank you,
Rachel
Hi Rachel,
Thanks for getting in touch! In Octopus, cleanup is handled entirely by our Retention Policies.
We do not advise removing any data from the database and instead relying on the retention policy features Octopus has built in.
There are a couple of ways you can confirm what your retention policies are removing. The first would be to check the Apply Retention Policies task that runs on your Octopus server. This task will tell you what has been removed from the Octopus server and the parameters it is following when doing so.
You can check your server’s package directory to confirm that this is working as expected for packages. It also removes old releases that are no longer active on the dashboard.
The retention policy configured on your Lifecycle is applied directly to individual targets and is managed on a per-target basis by using the DeploymentJournal.xml. We have more details in our Retention policy Tentacle cleanup and troubleshooting documentation.
Our developers have worked to ensure we remove orphaned data in the database wherever possible and will continue to do so as we develop the program.
If you have any further questions here, please don’t hesitate to let me know.
Best regards,
Daniel
Hi Daniel - Thank you for your reply.
We want to know if it is possible to run a script against the database, to get an aging report on how old the artifacts are in the database. This way we can verify we haven’t misconfigured Octopus Deploy and data is purging from the database as expected.
Thank you,
Rachel
Hi Rachel,
Sorry for the delay in getting back to you here. You should be able to achieve this just by using the API. Octopus is built as an API first program so any data you retrieve in the API should accurately represent what’s in the database.
Try the following
https://YourOctopusServer/api/artifacts/?order=asc
Let me know if this helps, or if it’s not quite what you’re after.
Best regards,
Daniel
Hey Daniel, thank you for your reply.
We tried the url you shared with us. looks like it contains some artifacts but not the whole lists of the project we had on the Octopus web.
I found there is a tool called Swagger UI from Octopus allowing me to use the API but I am not sure which command line would return me the list of the resources/projects/deployment history that are currently in the database. Can you give me some suggestions what command I should go for?
For example when i ran curl -X GET “https://xxx.xxx.xxx/api/projects/all” -H “accept: application/json” -H “X-Octopus-ApiKey: API-xxxx” --> i get bunches list of current project with project ID,“ReleaseCreationStrategy”, links etc. But I could not find the history of my project deployment list… Where should i find this information?
Do you have any thoughts?
Thank you,
Rachel
Hi Rachel,
Sorry for the delay in getting back to you. I have some ideas but I may need some additional information around your requirements here. Octopus does a good job at cleaning up old data with any significant size, such as packages, releases and deployments. This is covered in the Retention Policies documentation I previously linked.
It sounds like you would like to see a list of all projects and their deployment history. This sounds like a job for the Auditing feature. The Audit log allows you to search for any activity/changes in Octopus and show you when it happened, what was changed, and who made the change. You are able to apply any number of filters to the search, such as project, target, user, channel, etc.
So if you are using the Audit feature to search for all deployments for a specific project, you can manually cross-reference that with your retention configuration to ensure that your targets/server are currently keeping the desired amount of deployments/packages, or that the Octopus server is not holding onto any releases/packages.
The swagger UI is handy for seeing a list of the CURL commands you can run against the server and getting you started with the API, though it’s not the best for comparing data, which is why we have developed our auditing tool to do this function well.
I may be misunderstanding your exact requirements, if my above ideas are not sufficient, I’ll need to get some more details around your specific requirements and concerns you may have around the Octopus retention functionality.
Let me know what you think.
Best regards,
Daniel
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.