Storage Leak - Artifacts get NEVER deleted on tags
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
The modification to the artifact deletion behavior introduced a critical storage leak. I noticed this b/c our backups are increasing in size since some time in an INSANE amount. We talk about an increase of 50GiB per DAY. So I was searching for the reason, since we're productive, but not quite that productive
It turns out tags are the culprit and the modifications to the artifact deletion behavior. In fact gitlab ignores instructions now, which I think is not just an unexpected behavior and therefor a bad UX, bad also just straightforward bad. That is my opinion on this however. Gitlab should NOT keep artifacts if it gets instructed to not do it. I understand the intention behind keeping the latest version, but why would anyone want to keep an artifact that is 200 years old and the build never started again. If anyone wants this behavior this shouldn't be implicit, it should be an option in the runner stating: keep_latest: true and only then gitlab should do this. In our case, I don't care about artifacts at all, they carry state from an independent build step into the docker pipeline. After that artifacts can be safely deleted.
So this being an unexpected behavior, the issue which is causing the massive increase in storage requirements is actually that on tags, gitlab always thinks there is no newer version of those artifacts. Which is of course true, but there will never be. Never. So with every release we waste storage in the size of the artifacts now. So far so good, now I am here reporting it :)
See one recent tag:
And then this one, a few days before the last tag.
Steps to reproduce
See above
What is the expected correct behavior?
Delete when I tell to delete...