Live data from Hacker News

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

about.gitlab.com

151–160 of 176 posts

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

#151

Earlier quoted context omitted.

#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.

All replies here are missing that multiple users can stack their boosts, so no single individual needs to be paying 100 bucks a month.

I'm not missing that, what implies that I am?

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

#152
post #105

Earlier quoted context omitted.

> and it’s a small but growing segment They could have grandfathered the existing accounts into the 2000 minutes. Then the segment would no longer be growing and stay small, no?

Except in this case individual users will also grow. You'd have to do something like grant them their current usage plus some buffer (without letting them know ahead of time maybe, since otherwise this is gameable).

Why do you need a buffer? If you’re grandfathering in old and limiting new users more, what is gameable? Besides a small portion of people registering accounts in the short time between announcement and implementation?

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

#153
post #112

Earlier quoted context omitted.

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.

Given the rise of Sourcehut as some people's new goto and Github finally offering container registry, it seems like a good time to pull that trigger too. I as a whole like GitLab as an all-in-one solution.

Rise is a bit much. We barely think of the public facing Bitbucket or Sourceforge. I bet both are bigger than Sourcehut still.

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

#154

Earlier quoted context omitted.

Given the rise of Sourcehut as some people's new goto and Github finally offering container registry, it seems like a good time to pull that trigger too. I as a whole like GitLab as an all-in-one solution.

I love Sourcehut, but Sourcehut's only competitive right now in the indie/free software enthusiast market. I doubt Gitlab views them as a major threat.

Much like Sourceforge isn’t and Bitbucket is not the same sort of competitor or threat as a couple of years ago. The private version that is sold (Stash?) could be though.

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

#155

Earlier quoted context omitted.

Given the rise of Sourcehut as some people's new goto and Github finally offering container registry, it seems like a good time to pull that trigger too. I as a whole like GitLab as an all-in-one solution.

I love Sourcehut, but Sourcehut's only competitive right now in the indie/free software enthusiast market. I doubt Gitlab views them as a major threat.

That is what GitHub thought about Gitlab

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

#156

Earlier quoted context omitted.

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…

Hi, thanks for your feedback. We will consider making sure to clarify that going forward. Free users refers to users of the free tier of GitLab.

this isn’t a feedback loop for git

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

#157
post #142

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…

Pretty incredulous position to take when a company offering free stuff makes adjustments to their free stuff

What position do you think I took? I just asked some questions out of curiosity, I did not mean to take any position.

Do you have a blanket position against being curious about the business models or policies or statements of companies offering free stuff about their free stuff? Does that apply to facebook and google too?

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

#158

Earlier quoted context omitted.

All replies here are missing that multiple users can stack their boosts, so no single individual needs to be paying 100 bucks a month.

I'm not missing that, what implies that I am?

You're not; your reply is.

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

#159
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"?

That would probably be 280 minutes of "build time" to do your build in 70 minutes. My math is: they are going to call your 8 core CPU 16 vCPUs, because it's something cloud providers can charge money for but Hyperthreading/SMT doesn't really speed up builds that much. It does do something, but 2 threads scheduled on the same core is not going to be 2x faster than one thread being scheduled on that core. (It sure will use 2x the RAM, though, while it sits there waiting to execute instructions. They will charge you for that too!) Then, because they are running on a 64 or 128 core CPU with the same TDP as your consumer chip, things are going to be really clocked down -- your desktop may boost to 5GHz during the build (assuming you got a good cooler and overrode the time limits for boosting; who doesn't, though?), this thing will be running at 2.5GHz. So you will need twice as many actual CPU cores to get the same performance.

I am being very pessimistic with these numbers, but I am continually amazed at how slow computers in the cloud are compared to my desktop. And when you're being charged by the minute, there is no incentive to make the computers faster, of course -- the business incentive is to make them slower! Buyer beware. (To be fair, they are getting a lot better Wh/build out of their system than you are. If you were paying for the electricity and cooling and got paid no matter how slow the build was, you'd make the same decision.)

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

#160

Earlier quoted context omitted.

Given the rise of Sourcehut as some people's new goto and Github finally offering container registry, it seems like a good time to pull that trigger too. I as a whole like GitLab as an all-in-one solution.

Rise is a bit much. We barely think of the public facing Bitbucket or Sourceforge. I bet both are bigger than Sourcehut still.

I was rooting for Bitbucket and Mercurial 7 years ago. Shame.
Post reply on HN