I am a bit worried that our storage usage did not go down, despite Gaetan changing the setting to not keep the latest artifacts. In fact, the usage has grown by 20GB since last evening. We have two weeks (until October 20th) to understand how to bring this value down to under 250GB.
Could it be that some clean-up mechanism has not triggered yet?
I seem to remember that they run a cron job every hour to clean job artifacts. But I fear that, because they were once marked as "don't expire", the cron job will not consider them.
Yes, maybe not retroactively indeed.
We can let it run for 24h with the new setting, to see if there's not another mechanism which catches up
I've tried deleting a few stale branches (that were not deleted by coqbot for some reason) to see if that helps.
150GB have been freed. (No idea if it is related to the stale branches being removed or if it is a cron job finally kicking in.)
More likely the latter.
We will see if it continues going down in the next few hours / days.
Guillaume Melquiond said:
I am a bit worried that our storage usage did not go down, despite Gaetan changing the setting to not keep the latest artifacts. In fact, the usage has grown by 20GB since last evening. We have two weeks (until October 20th) to understand how to bring this value down to under 250GB.
isn't the enforcement date in february?
https://gitlab.com/coq/coq/-/jobs/2258609513 (open PR with no recent activity) still says "They will not be deleted"
maybe we need to delete all the pr branches to force a reset
Gaëtan Gilbert said:
isn't the enforcement date in february?
I am pretty sure that yesterday, the enforcement date was October 20. But the text has been modified since then and there are no date anymore, just "the new limits on Premium / Ultimate will be applicable when they upgrade" (no idea what "upgrade" means). They have also added "these changes do not apply to community programs". So, perhaps it is no longer an issue for us.
Actually, the sentence is still there, but now in a double-negative way: "storage limits will not be applied before 2022-10-19"
And there is also the sentence "Community programs will have the limits applicable for GitLab Ultimate", so this is still relevant for us.
So, if I understand correctly, they initially intended to enforce the limits on October 20. But since then, they have noticed that job logs count toward artifact storage, yet they cannot be removed (?). And since they are not confident they can implement a solution in the next two weeks, the enforcement date has become vague.
it would be nice to actually analyze what uses storage instead of deleting random stuff and hoping it's enough
for instance we keep most artifacts for 1 month, it's probably too much tbh, but how much do we need to reduce the limit?
Ok, we can try to collect data next week
It is a bit less pressing than the CI minutes
Btw, the bug minimizer relies on having artifacts available for both the base of the PR (whatever version of master it's based on) and the tip of the PR. So it'd be nice to not delete artifacts from master too eagerly
Hum, I think that the actions that we've applied on artifact removal do not affect how artifacts from master are removed because they were already not preserved very long when they do not correspond to the tip of the branch anymore.
not very long = 1 month?
our current usage is currently 2.5 TiB acccording to the interface
(the vast majority as artifacts)
artifacts or logs, right? They are not distinguished
the UI for storage quotas got updated at some point Screenshot_20230131_161902.png
still can't tell how much is logs vs other artifacts though
Last updated: Feb 01 2023 at 16:03 UTC