|
|
|
|
|
by dnsmichi
1380 days ago
|
|
> What does this cover? https://about.gitlab.com/pricing/faq-efficient-free-tier/#ma... provides a list of what counts towards the storage limits, and also ways to manage, reduce and cleanup storage. > Does it cover the size of a git repo? Build artifacts, both temporary and exported to packages? And what about Docker images? Yes, they all are storage types that add to the overall storage consumption. > Docker images concern me the most. It's terribly easy to build and use Docker images that are >100MB, and 50 of those easily go beyond 5GB. Two projects with nightly builds easily go beyond that in a month even when doing nothing at all. You can define container cleanup policies within the registry, matching on age, tags, etc. https://docs.gitlab.com/ee/user/packages/container_registry/... |
|
Yeah, I gotta say - this is not great. Particularly given the overarching guidance on GitLab CI is "break everything up into 30 jobs", having to store containers as either an artifact or in the registry in order to pass them to sast or test jobs or w/e means that most projects are going to hit this limit instantly. Our largest work project has registry usage sitting at 800g - admittedly, we could be a lot better at cleaning up tags. But staying under 50 for the whole namespace, not even just registry, is going to incredibly difficult.
A fair while ago, we used self-hosted and swapped to SaaS because it was the same price and we didn't have to deal with upgrades etc - and we used our own CI runners anyway. Is the unspoken intention to force users like us onto self-hosted? Should we instead be using a non-GitLab registry to store this stuff?
Very long term GitLab user, very disappointed by this.