We've been struggling with this GitLab storage change, even consulting with GitLab reps on strategy logic between namespace versus repositories. It's still very confusing, especially if you were using their other offerings like CI/CD build systems and associated build artifacts storage.
The artifacts storage is that one that's just tough to figure out when dealing with large builds. We have already offloaded all our CI/CD to our own hosted GitLab runners, but apparently storing the artifacts afterwards (which by default GitLab always stores the most recent builds) MUST use their storage, we can't offload it to our own servers.
What's the error / job logs you are seeing with having the project settings disabled for keeping the latest artifacts? The async operation to delete artifacts can take a while. Suggest to continue on the GitLab community forum: https://forum.gitlab.com/ where more folks can help. If you continue seeing the problem, also suggest to create an issue as a bug report. Thanks! https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_t...
I might be alone, but I'm really struggling with this line of fixes from Gitlab.
To be clear - I'm all for Gitlab charging, I think that's fair and reasonable.
However, if they're gonna charge for artifact storage, they need to provide first-class tooling to manage the storage.
My experience is almost exactly the same as the OP's. Huge artefact storage from builds, the scripts to clean up don't work.
> The async operation to delete artifacts can take a while.
How do I tell if something has succeeded or failed then? Last time I ran the scripts, no errors were mentioned, but nothing was tidied up.
Cleaning this stuff up shouldn't be via hacky scripts or community projects. It should be a mandatory requirement for managing an aspect of my account that's about to become very very expensive.
Oh it feels great to learn I'm not alone in this problem. I completely agree with everything noted here.
The current interface provided for removing the artifacts on GitLab just does not work. There is no feedback; no confirmation. We just uncheck a box and just cross our fingers since there is no other step noted.
Even with the new guidance provided, it's still additional jumps through other codebases just to see if it works. I'm now worried that if I go through this new process, I'll end up right back at the same issue.
Just in case anyone from Gitlab is monitoring this thread, there remain issues[0][1][2] in the artifacts listed both in the UI, and returned from the API, resulting in artifacts unable to be deleted.
It's clear that the gitlab dev team are aware of these issues, but given they've been open for years, I'm not convinced they'll be resolved before the pricing changes kick in, in a little over a months time.
If not addressed, according to the FAQ, teams builds will start failing, as they'll be unable to publish artifacts, and unable to manage the artifacts, essentially leaving them blocked.
The artifacts storage is that one that's just tough to figure out when dealing with large builds. We have already offloaded all our CI/CD to our own hosted GitLab runners, but apparently storing the artifacts afterwards (which by default GitLab always stores the most recent builds) MUST use their storage, we can't offload it to our own servers.
The instructions for removing the most recent artifacts also just never works (https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#k...)
So in our monorepo with multiple Windows and Mac applications, we are now stuck with lots of GB that are just there, currently unable to delete.
This is causing us to dramatically revisit our strategy of using GitLab and might force us to other tools.