We’ve migrated OD v2022.4 from one VM to another and followed the instructions to copy the packages folder from the old server to the new. Everything worked fine, except that when we now update the lifecycles with shorter retention times of keeping 3 releases.
But he packages aren’t deleted and we get the following message:
MyProject.BackendWeb.0.0.1 was published on 1/20/2023 12:00:51 PM +00:00. It will be kept because published after the cutoff date.
This specific package was created on the old server 2019-09-20, and there are more than 200 newer packages so this should be removed. But as we have copied the packages from the old server, this file gets a created Created date of 2023-01-20, and keep the Modified date of 2019-09-20. Is it so that OD only checks the Created date when comparing with cutoff date specified in the lifecycle?
Thanks for reaching out to Octopus Support!
Sorry to hear you’ve run into the issues you described.
It is possible that the internal repository’s package re-index process kicked off on the new server before the folder was copied over. This would have resulted in the packages being re-move and then re-added with new dates when transferred across.
There’s limited options when it comes to fixing this. If you have a database backup from before on the old server, you should be able to copy the data from the NugetPackage table on the old instance to the new instance and then run a re-index, which should fix any packages that existed before the move.
I hope this helps, I’m sorry I don’t have a better solution for you here but don’t hesitate to reach back out if you have any questions or run into any other issues.
Ok, but can I truncate the table in the database and then re-run the indexing process?
To avoid this problem for future migrations, I think that you should add this information to the migration documentation, and perhaps also make sure that the installation doesn’t auto-start the Octopus service to avoid the risk of indexing to early.
Truncating the database and re-running the indexing would likely re-add the same packages with the same date.
As package retention cannot delete any packages currently linked to a release, another solution here may be to reduce your package retention policy in Library > Packages to a lower value that will allow these packages to be successfully cleared out.
I’m not able to confirm 100% if that method would correct the issue you’re experiencing.
The best way I can recommend to resolve this is if there is no release associated with the package in question (which I assume there isn’t if you have retention set to 3 days), then Octopus should clear out this package automatically when repository retention kicks in.
Setting this to a shorter time period will likely kick-off repository retention and remove those packages that aren’t associated with releases.