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

61–70 of 176 posts

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

#61

Post by JoshTriplett »

ivalm wrote: post #45
JoshTriplett wrote: post #31

Earlier quoted context omitted.

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.

What about if there's one instance type, but sometimes that instance gets upgraded so that the same things take less time? Is there a unit that would make more sense than "minutes", and be stable over time?

For instance, "time to compile XYZ well-known project"?

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

#62

Post by time0ut »

Gitlab's SaaS offering is an excellent product. It is absolutely worth paying for. Their free tier was and still is very generous. I hope this isn't a signal that they are having trouble. I've kind of naturally shifted 90+% of my work over the Gitlab over the past year. I love it and want to stay!

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

#66

Post by WindyLakeReturn »

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?

Probably could just include a * that points to the infrastructure it runs on with a link to the update history of that infrastructure. It only becomes an issue when the infrastructure isn't standardized, but that is just exposing the underlying issue where the same build won't take equal time due to a difference in infrastructure.

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

#67

Post by masklinn »

time0ut wrote: post #56
jchw wrote: post #40

Earlier quoted context omitted.

You can pay for Discord. Admittedly, I do. It's not that Discord is perfect, I have a lot of personal gripes with it. But it's still significantly better than where I came from (Skype) and I use it a lot so it seems fair enough. Discord Nitro also thankfully pivoted from being a games service and the features it does provide are nice to have. (Larger file uploads, better stream quality, cross-server emoji.)

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, but 15 boosts for that doesn't really seems worth it.

As to price, a boost is $5 so a level 3 server is indeed $150 (level 2 is half), however Nitro ($10) provides 2 boosts and 30% off all boost purchases, meaning you can max out a server for $108, or 55.5 for a level 2. Nitro classic is only $5 and also provides 30% off of boosts, but doesn't include the free boosts, so it comes out at $110 to get a level 3 server on your own.

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

#68

Post by nscalf »

davnicwil wrote: post #51
nscalf wrote: post #39

For smaller projects who aren't ready to start spending yet, it's pretty trivial to spin up your own runners on a server. Not sure how it scales, but Gitlab has pretty solid guides on how to make one. It took me maybe an hour the last time I looked at it, worth checking out. Definitely easier to drop $10 than maintain that though, I'm a fan of Gitlab's CI/CD infrastructure.

This thing of spending like an hour setting up a runner is one of the things I wanted to address with https://boxci.dev - A CI service I’ve built with a similar bring your own runners model but where “setting up the runner” consists of just installing a package, literally done in seconds :-) You should check it out.

Awesome! I’m a couple weeks from turning my attention to ci/cd for a side project. I’m going to bookmark this and I promise I’ll check it out!

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

#69

Post by snovv_crash »

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…

Is there an equivalent of `ccache` for Rust? For C++ it's been a total lifesaver, I've introduced it in multiple organizations for massively reducing (average) build times, even by sharing the cache on an NFS drive between multiple machines.

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

#70

Post by lloeki »

time0ut wrote: post #57
acoard wrote: post #53

Earlier quoted context omitted.

Can you share a bit more about this? I'm interested in setting this up myself. A link the docker image or name I can google? To be clear, you store all your code on Gitlab's servers (i.e. not self-hosting git instance) but just "outsource" the CI/CD work to your homelab? That's my ideal.

You run an agent called the GitLab runner. You configure it with a token from your Gitlab.com group or repo (depending on where you want the runner to be available). You tag the runner and reference it by tagging CI jobs you want to run on it. The runner polls for outstanding jobs and then executes them. It is extremely flexible in how it does this. In our case, the runner manages a fleet of executors using docker+ma…

I did macOS runners this way, combining the runner with the VirtualBox executor. Best part is once you set up the base VMs (one per macOS version), the runner is smart enough to take a snapshot right after boot and restore that on subsequent runs, which not just makes job running stateless, but also makes job worker boot about 2s.
Post reply on HN