Live data from Hacker News

Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

about.gitlab.com

111–120 of 176 posts

Re: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

#111
post #99
post #58

Earlier quoted context omitted.

Compared to Slack, which sells you basically the same thing but with a "business" tag for $8 per person and month it doesn't seem like that much. On the other hand Slack's pricing is pretty crazy.

Is it? $15-30/head sounds like a lot, but these are employees you're paying 30k+ to in salary alone, if the addition of slack makes them 1% more efficient per month, that blows past the $15/head. Forget the tech companies with employees that easily crest 200-300k in costs after insurance and other benefits. There's a lot of audits and regulation, in addition to tighter security, that Slack needs to prove to its enter…

You are comparing efficiency like in "with Slack" and "without Slack", but in fact it is a "with Slack" vs "with another messenger". On a previous job we used Telegram for work communication. It has bots and stuff, and it's blazing fast. And it's free.

Re: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

#112

Their existing policy has never made sense to me. You can only give away so much stuff on a free plan. I don't think CI/CD is cheap. Buying extra minutes for $10 (not per month) is completely reasonable. At some point I feel uncomfortable using a free plan that is obviously unsustainable.

Business models which leverage network effects often subsidize things to build out a network. I wouldn't feel bad about it. That said, this move seems 100% reasonable. I care about having a free tier. If they were killing the free tier, I'd be sad. But if I'm not paying anything, I'm okay being required to make my CI/CD pipeline efficient for my benefactor. I'd even take less than 400, gladly.

GitLab earned their market position by offering free private repos. They leveraged that position to get the funding to massively ramp up their enterprise features while GitHub was burdened with thousands of open source users. Now GitLab is cashing in and I don't blame them. Their product is excellent. It's basically an all-in-one package for small to mid tech orgs.

Re: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

#113
That page links to https://about.gitlab.com/solutions/open-source/program/ for determining if your project can have more free minutes. It sounds like that says if you have a public repo you get a bajillion (50,000) free minutes. That seems like a crazy good deal.

Re: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

#114

One thing that always confuses me about the business factors in this kind of announcement, where they say that the vast majority of users won't be effected: > We evaluted CI/CD minute usage and found that 98.5% of free users use 400 CI/CD minutes or less per month. Okay, so just that 1.5% of free users, each using at most 1600 minutes more than the 400 under the new limits... is enough cost to actually matter and mak…

It’s because cost isn’t the issue. The change is designed to convince more free users to switch to a paid account.

Re: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

#115
post #100

One thing that always confuses me about the business factors in this kind of announcement, where they say that the vast majority of users won't be effected: > We evaluted CI/CD minute usage and found that 98.5% of free users use 400 CI/CD minutes or less per month. Okay, so just that 1.5% of free users, each using at most 1600 minutes more than the 400 under the new limits... is enough cost to actually matter and mak…

These are carefully constructed truthful statistic lies. Of all the free users, how many of them even have a repository? Out of all the users who have a repository, how many of them actually make any use of CI/CD? They are saying "1.5%" to make it sounds small, but those 1.5% could account for a significant portion of total minutes of CI/CD used.

This is exactly it. 1.5% of users does not equal to 1.5% of CI/CD minutes. And such messaging isn't always dishonest. If you have 99 users using 100 minutes each and 1 user using 10 million minutes, setting the max limit to say 1000 is a net benefit for the system and its users, at the expense of the one outlier.

Re: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

#116
post #56

Earlier quoted context omitted.

The pricing for this seems totally crazy to me. If I recall correctly, maxing out a server is like $160 a month, right?

This and that are different things though. Nitro is for individual accounts and provides features for you as a user, boost is for the server and provides features for every user of the server. Maxing out a server takes 30 boosts but the level 3 perks seem pretty… thin on the ground: - +100 emoji (from 150 to 200) - 384Kbps audio (from 256) - 100MB uploads (from 50) - custom URLs Only the third one is somewhat useful,…

#4 is huge, especially if you're running the Discord to promote something else like a Twitch channel or a game.

Is it worth the cost? Probably not. But I'd put it above larger uploads in terms of importance, and my discords hit the upload limit pretty often.

Re: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

#117
post #88

Their existing policy has never made sense to me. You can only give away so much stuff on a free plan. I don't think CI/CD is cheap. Buying extra minutes for $10 (not per month) is completely reasonable. At some point I feel uncomfortable using a free plan that is obviously unsustainable.

I am not sure whether their CI/CD has been a main driver, but their investment rounds haven proven that they have built up a very positive image. So in a way attracting users for free can bring money to the company. But you are right: Such model is not sustainable for very long.

I've personally moved two separate teams to switch to gitlab exclusively for its CI features.

Re: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

#119
post #100

One thing that always confuses me about the business factors in this kind of announcement, where they say that the vast majority of users won't be effected: > We evaluted CI/CD minute usage and found that 98.5% of free users use 400 CI/CD minutes or less per month. Okay, so just that 1.5% of free users, each using at most 1600 minutes more than the 400 under the new limits... is enough cost to actually matter and mak…

These are carefully constructed truthful statistic lies. Of all the free users, how many of them even have a repository? Out of all the users who have a repository, how many of them actually make any use of CI/CD? They are saying "1.5%" to make it sounds small, but those 1.5% could account for a significant portion of total minutes of CI/CD used.

This seems... ambiguous, actually. I for one automatically took "free users" to mean free users of the CI/CD feature, not free users of GitLab. Meaning, the set of people who use > 0 CI/CD minutes. I'm actually surprised if that's not what they mean, given the entire point of the discussion is about how this affects users of the CI/CD feature. It's one thing to state things clearly and let the reader make incorrect inferences just due to natural assumptions, but writing the text itself ambiguously to induce that effect is a little different.

Re: Gitlab reducing free tier CI/CD minutes from 2000 to 400 minutes

#120
post #22

I've never really understood "minutes" as a unit of build work. What kind of server are we talking about? What CPU? How much RAM? How fast is the storage access? Is my instance virtualized? And if so, do I have dedicated resources? I have a build that takes around 70 minutes on an 8-core i9 with 32 GB of RAM and M.2 SSDs. What does that translate into for Gitlab "minutes"?

What would be the most immediately understandable way to present that? Suppose they added new, faster servers in the future; what unit would make the most sense to offer that won't change in the future?

A generic "build credit" term could be better, maybe - with some details about what one credit gets you. Maybe one build-credit is normalized to "One minute on an 'n1-standard-1' with 4GB of RAM and 40GB of storage."

Under a system like that, users could maybe choose between a couple of different worker types. Or if there's only ever the one type, periodically the 'n1-standard-1' could be swapped out for whatever is the latest-greatest for the same price.

Post reply on HN