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

Re:Gitlab reducing free tier CI/CD minutes from 2000 to 400 ... by time0ut on Thursday September 03, 2020 @03:12PM (#24367608)

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+machine. I believe this is similar to how Gitlab does it internally.

See https://docs.gitlab.com/runner/

[ Parent | on HN ]

Re:Gitlab reducing free tier CI/CD minutes from 2000 to 400 ... by lloeki on Thursday September 03, 2020 @03:52PM (#24368100)

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.

[ Parent | on HN ]

Re:Gitlab reducing free tier CI/CD minutes from 2000 to 400 ... by e12e on Thursday September 03, 2020 @03:57PM (#24368155)

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.

[ Parent | on HN ]

Re:Gitlab reducing free tier CI/CD minutes from 2000 to 400 ... by ddoice on Thursday September 03, 2020 @04:03PM (#24368240)

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

[ Parent | on HN ]