I am using Harbor Container Registry as my container registry, as the reader may have noticed already. A challenge I have with this system is that removing old versions of a conatiner is not really understandable to me.
My requirement
When coding and pushing code to the server, my CI pipeline starts and typically builds a container image (in case there is an image to be built). This then gets pushed to Harbor with the tag latest, or main, depending on the context.
I mostly use these images for testing and short-tem; I in particular use this workflow to actually tag images when releasing them. In this case, the same workflow builds the same image and tags it with x.y.z or so, which are the images I actually use.
Now this workflow has a flaw in it: The number of untagged images grows over time, and nobody will ever use them. The reason is that my default image with the tag main gets overwritten essentially with every push that I make, and the old image then obviously has to get untagged. These untagged images should be deleted.
Setting up the deletion
Now Harbor provides something for that out of the box: In a project, one can setup Policies, which essentially is: Define which images should be kept.
For my project, I defined the following policy: “For the repositories matching **, retain always with tags matching **”. When setting up the policy, this looks as follows:
Nice work, and now we are done! One may think. Turns out, we are not. Altough quite obvious when knowing about it, this was not obvious to me, and that’s also the motivation for this post.
Actually run this policy
It may make sense to do a dry run first, to verify that the correct thing happens. Just hit the button on the same screen. Note, approved for you: If the system tells you that this can happen serious consequences then you did not click “Dry Run”.
Now again on the same page, you find a “Schedule”, which is set to None by default. As long as this is the case, nothing will happen! So setup some schedule here; I chose “weekly” as this is definitely good enough for my case.
Conclusion
I know that this is common knowledge, but as it turns out: Reading really helps…