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

71–80 of 176 posts

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

#71

Post by e12e »

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…

The ci/gitlab runner bit, might be the best part of gitlab - it's pretty straightforward to set up (we self-host gitlab and ci).

The omnibus-installer (for gitlab itself) works - but knowing a bit about rails (gitlab is a ror monolith) - it's a bit terrifying.

But the runner is very nice.

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

#73

Post by ddoice »

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…

Yep, I have a raspberry Pi with gitlab runner and works great.

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

#74

Post by muspimerol »

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

All you have to do is look, they list the shared runner specs: https://docs.gitlab.com/ee/user/gitlab_com/index.html#shared...

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

#75

Post by Camas »

snovv_crash wrote: post #69
dmm wrote: post #24

Earlier quoted context omitted.

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

https://github.com/mozilla/sccache

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

#77

Post by marcosdumay »

etaioinshrdlu wrote: post #46

Are we in a "belt-tightening" cycle? Noticing that Docker and now Gitlab are reducing their super generous free tiers...

There is a global recession out there, of the kind that only happens once every 3 or 4 decades.

Even if those companies aren't losing revenue (they probably are), there is less investment money too, so they are still impacted.

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

#78

Post by papaf »

kevincox wrote: post #60
dmm wrote: post #24

Earlier quoted context omitted.

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

You should be caching the builds of your dependencies. This is very easy with cargo and GitLab. I think encouraging people to optimize this is a reasonable cost to push onto the free users.

To add to your point, the caching is done by adding a cache entry to .gitlab-ci.yml :

  variables:
    CARGO_HOME: $CI_PROJECT_DIR/cargo

  cache:
    key: "$CI_JOB_NAME"
    untracked: true
    paths:
      - cargo/
      - target/

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

#80

Post by rolleiflex »

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.

Relying on an obviously unsustainable free plan to build something always felt icky to me, because it will inevitably break, and then you will have to deal with the fallout of a perhaps now-unsustainable project of yours, your investment upon which then could end up possibly sunk, leaving you worse off than not having started the project in the first place.

Paradoxically, a lower free tier makes me a lot more likely to use Gitlab CI now, since I now know they know their costs and limits, and from now on, not eating the cost for a future drop of the hammer in an undetermined timeframe.

Post reply on HN