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

41–50 of 176 posts

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

#41

Post by jchw »

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.

I think a good free tier still makes sense as long as it seems sustainable overall. For example, if a lot of people are willing to pay for at least a basic plan, I feel a little better.

I think for CI/CD having a generous free tier is great because it makes it easier for people to get started and really dig into a project, not to mention the obvious benefit to open source that works as a continuous PR machine. Practically everyone knows what Travis CI and CircleCI are.

I still agree that it can be unnerving at times. I worry about services that seemingly offer no paid tiers. Like, draw.io. Thankfully draw.io actually seems to be sustainable, but you wouldn't guess it based on their very unobtrusive app!

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

#42

Post by oehtXRwMkIs »

dmm wrote: post #24
rumanator wrote: post #21

Earlier quoted context omitted.

> 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 ru…

Plus Rust by design avoids all sorts of bugs leading to less tests imo. Python for example you really want a lot of testing, maybe even contracts, but with Rust I find that many of those tests are irrelevant.

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

#43

Post by deastman »

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

We define Pipeline minutes as the execution time for your pipelines. You bring up an interesting point, though. So today, for our Linux Runners on GitLab.com, those Runners are currently offered only on one machine type, Google Compute n1-standard-1 instances with 3.75GB of RAM. Our current Windows Runners on GitLab.com are Google Compute n1-standard-2 instances with 2 vCPUs and 7.5GB RAM.

In the future, for Linux and Windows Runners, we will offer more GCP machine types. For our soon to launch macOS Build Cloud beta, we are planning to start with one virtual machine size and then possibly offer different machine configurations at GA.

And yes - the virtual machine used for your build on GitLab.com are dedicated only to your pipeline job and immediately deleted on job completion.

Finally, the only way to know how long your current build job will take on a GCP n1-standard-1 compared to the 8-core machine is to run the job and compare the results. I assume that your 8-core machine is probably a physical box, so you should of course, get better performance than a 1-2 vCPU VM.

A few reference links:

https://docs.gitlab.com/ee/user/gitlab_com/#shared-runners

https://gitlab.com/groups/gitlab-org/-/epics/1830

https://gitlab.com/groups/gitlab-org/-/epics/2426

Darren Eastman: Product Manager GitLab Runner

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

#44

Post by toupeira »

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

If that's an Open Source project you could apply for a free Gold license and get 50'000 minutes per group per month (see links in the article).

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

#45

Post by ivalm »

JoshTriplett wrote: post #31
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"?

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?

I mean like other public cloud providers it would make sense to have instances and per minute pricing for an instance. If there is only one instance type that's fine.

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

#47

Post by karlerss »

jamesh-gl wrote: post #32
rumanator wrote: post #21

Earlier quoted context omitted.

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

GitLab Product Manager here - We’re working on ways to run fewer tests OR only the necessary tests earlier in a pipeline so you get to a result in fewer minutes. The first project towards this in the product is https://docs.gitlab.com/ee/user/project/merge_requests/fail_... which we hope to bring down to the Core tier soon. -James H, GL Product Manager, Verify:Testing

I think most test runners have a --stop-on-failure feature, but using it has the downside of not giving you the complete list of failing tests.

If you haven't touched your gitlab pipelines for a few months, check out DAG pipelines [0] - I got my web project deployment pipeline down from 25 to ~12 minutes by running tests sooner.

[0] https://docs.gitlab.com/ee/ci/directed_acyclic_graph/

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

#48

Post by ajford »

sushshshsh wrote: post #25
viro wrote: post #20

Earlier quoted context omitted.

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 understan…

Build vs Buy is a very individual decision that should be based on your team and your product.

At my last employer, we used a free tier of CI/CD through CircleCI as it was sufficient enough and easy to spin up for testing a couple of small internal libraries we needed to hook things together with a SaaS product we were using. We weighed the benefits and came up with a number that balanced the estimated cost of implementation and running cost of self-hosted against the free tier offering and estimated cost of implementation there.

Once you factor in engineering costs and the additional server to maintain, it made sense to go hosted for us. But every team is different, and hardware cost isn't the only thing. You need to consider the running cost of utilities, maintenance, and in the case of larger equipment, even cooling costs.

That said, for personal projects, yeah, I just kick things onto my home file server, since it's running anyways, and normally has nearly no load other than managing my ZFS and occasional backup operations.

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

#49

Post by zepolen »

sushshshsh wrote: post #5

Metering of services like this only makes sense for organizations that don't have the time or expertise or desire to maintain the open source, self-hosted version themselves. Raspi and similar devices will some day hopefully rid the world of this tyranny of having to trust a website like this and pay them for eternity and hope they dont go down and hope they dont raise prices (oops) and hope they dont obfuscate prici…

99$ for 50,000 hours is a steal. You could barely rent a dedicated server for that amount of money, let alone the maintenance.
Post reply on HN