Library Package Retention

PsyVision's Avatar

PsyVision

06 Feb, 2018 02:08 PM

Hello,

At what point is the library package retention policy run and is there a way to manually run it?

We noticed that Octopus was keeping a lot of packages for a particular project, we've since changed the release retention policy and it appears the releases have now been dropped from Octopus - at least I am unable to find them via the project's Releases page.

However, when looking in the library and on disk I am able to see the packages still there. The retention policy for packages not used in a release is set to 7 days. The packages in question were pushed in September 2017.

Is there a way (CLI/API) to tell if the package is in use and if so, by what?

Octopus v4.1.5.

Thanks,
Richard

  1. Support Staff 1 Posted by Alex Rolley on 09 Feb, 2018 04:38 AM

    Alex Rolley's Avatar

    Hi Richard,

    I have to apologise for the length of time it has taken for me to reply to your question.

    The library package retention task is run every 4 hours, and can be re-run at any time by heading over to your Octopus Servers Task page, filtering on Apply retention policy and re-running the latest task.

    As for investigating why packages haven't been removed, on the same task that we identified in your Task log above you are able to export the raw task log and review why packages have been left on disk. If you have any questions regarding the log or if anything doesn't add up please attach the log file and we would be happy to help work through the issue with you.

    Thanks Richard, I look forward to hearing how you go,

    Regards,

    Alex

  2. 2 Posted by PsyVision on 09 Feb, 2018 08:16 AM

    PsyVision's Avatar

    Hi Alex,

    No worries on the delay!

    I've re-run the task and when looking at the raw log noticed the library package aspect. This is an example of the package that is being kept:

    08:06:46   Info     |     jump.0.1.17 was published on 20/09/2017 11:10:54 +01:00. It will be kept because the project JUMP uses #{...} references in the package ID field and has deployed a package with this id before.
    

    Not being familiar with the project myself, and given that I hadn't recommended the use of #{...} with package names to others in the company, I hadn't realised this was being used.

    I'm going to change this as it doesn't need to be a variable and then re-run the retention. I'm not sure if this will then allow the packages to be removed automatically though, I guess Octopus may now see them as tainted.

  3. 3 Posted by PsyVision on 09 Feb, 2018 08:59 AM

    PsyVision's Avatar

    I've manually removed the extra packages from the library and can probably consider this closed.

    Cheers!

  4. PsyVision closed this discussion on 09 Feb, 2018 09:00 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac