The number of release process executions is steadily increasing. Concepts like Continuous Delivery and Deployment emphasize releasing as often and as automated as possible. While developers and customers enjoy the bright side of the improving software development processes, operations has to deal with the flip side. More releases mean more storage usage. Increasing process quality requirements like archiving every delivered release (or at least, every release which is deployed on a production system) in a structured, easily accessible manner somewhere means more storage. But resources like storage are limited. So you have to collect the garbage sooner or later – and if you have a lot of releases, you desperately want to automate this cleanup process.

So, if you use Sonatype Nexus as intensively as we do and you sooner or later face storage limitations: this blog post might be a solution for you.

Nexus offers scheduled snapshot repository cleanup and lets you define a filter specifying which artifacts to keep and which to delete. Unfortunately, Nexus does not support this for release repositories because releases are understood to be stable versions, on which other projects might rely. In fact that is the case for several of the libraries and software packages we develop and deliver. But there are also project-specific criteria and rules that allow us to determine whether a release is still in use somewhere or not. We examined several potential criteria such as release date, classifiers, the person who deployed the release into the Nexus… and discovered that we can make sure that no dependencies are broken in any project if we keep a project-specific number of the latest releases. So for some projects we store the last three releases, for others we keep seven or eight releases in our Nexus. Of course, you have to find your own criteria and rules.

The next step is the automation of the cleanup process. Because we deploy to Linux servers exclusively, we decided to automate our cleanup process as a shell script. Feel free to use it for your own purposes or extend the script and send us a pull request on GitHub: https://github.com/akquinet/nexus_cleaner.git

The last step is to make the execution of the script transparent and configurable for the developer teams. One way to achieve this is to let your Nexus server become a Jenkins slave and configure the script execution as a Jenkins job instead of configuring it directly as a cron job on the Nexus server. There are probably a couple of other ways to achieve the same thing.

However you choose to do it, the basic steps to implement an automated cleanup process are as follows:

1. define project-specific criteria and rules
2. extend the provided script (https://github.com/akquinet/nexus_cleaner.git) according to your needs or create your own creative solution (Java App, Web App, whatever)
3. implement a transparent and configurable solution to perform the job (e.g. script execution via Jenkins)