Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

about.gitlab.com

Post reply on HN
Print view View original

21–30 of 176 posts

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

#21

Post by rumanator »

dmm wrote: post #12

This is only about seven builds per month for my Rust project, not too bad but something I'll have to keep in mind. Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects? I just can't get myself to use Dyn...

> Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects?

No,not really. I mean, in healthy projects build times are dwarfed by the time it takes to run tests. In web development projects even the delivery and deployment steps dwarf build times.

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

#22

Post by nrclark »

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

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

#23

Post by vkgfx »

bachmeier wrote: post #16

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.

> At some point I feel uncomfortable using a free plan that is obviously unsustainable.

This describes how I've felt about Discord for years.

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

#24

Post by dmm »

rumanator wrote: post #21
dmm wrote: post #12

This is only about seven builds per month for my Rust project, not too bad but something I'll have to keep in mind. Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects? I just can't get myself to use Dyn...

> Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects? No,not really. I mean, in healthy projects build times are dwarfed by the time it takes to run tests. In web development projects even the delivery and deployment steps dwarf build times.

> in healthy projects build times are dwarfed by the time it takes to run tests

I don't doubt that's often true but many Rust projects may be outliers here. A full, non-incremental build of a Rust project involves building all of its dependencies. This can add significant amounts of time if a project uses a big framework like Actix-web, which adds many dependencies.

My tests however run very quickly, ~1ms each. So running thousands of tests only takes a few seconds, even on relatively slow gitlab runners.

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

#25

Post by sushshshsh »

viro wrote: post #20
swebs wrote: post #13

Earlier quoted context omitted.

Well you can already self host Gitlab on your own server if you want.

I honestly don't understand what he is complaining about.

I'm suggesting that $4 per month where I have to estimate the number of requests I will actually make is actually not that good of a value compared to self hosting on a raspberry pi.

The devices will pay for themselves within the first year and generally my philosophy is to avoid building your operation around 50 services cobbled together because there is a possibility you will spend more dev time trying to understand a service's idiosyncracies than actually just rolling your own.

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

#27

Post by agarzenm »

Do they have metrics on how many free tier accounts actually use the CI/CD feature and of those how many exhaust the former 2000 minute quota?

I am asking because my use is definitely in the minority of the user base which is just slapping projects into a managed git repo that is not owned by Microsoft.

This was before github decided to allow private repos for free.

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

#28

Post by sushshshsh »

nrclark wrote: 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"?

Probably a lifetime :) Just kidding.

Either they went the cheap route and stuck it on some price efficient EC2 instances, or they went the vogue-but-expensive route of lambdas for "rapid processing and ease of development"

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

#29

Post by codegladiator »

bachmeier wrote: post #16

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.

The free mins definitely got me started. and later I just had to attach my k8s cluster with gitlab and allow worker pods for my project builds.

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

#30

Post by MichaelBurge »

nrclark wrote: 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"?

Presumably they're the same machines as before, so anyone affected already knows the translation.
Post reply on HN