Hacker News Reader

Comment by bdcravens | Hacker News Reader

Isn't one of the main selling points of Gitlab their built-in CI? Anyone using Gitlab use an external CI?

It appeals to me as someone who likes Circle's CI offering but wants to move away from Github.

I tried using Gitlab's CI and was surprised at how limited it was. The Gitlab CI syntax was harder to follow, and my integration tests took 17m to run when they ran in almost 1/3 the time on Circle.

A big part of the problem was that CircleCI lets me use an instance with 8 CPUs / 16 GB RAM with just a config file change[0], whereas every Gitlab instance is 1 CPU / 3.75 GB RAM unless you host your own runners.[1] But if I'm paying a company to manage CI, I don't want to provision my own hardware infrastructure

[0] https://circleci.com/docs/configuration-reference#docker-exe...

[1] https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner...

Related, GitHub has had 'use more powerful hosted runners' in the pipeline for over 2 years[0]. This issue replaced another now-deleted issue[1] from July 2020.

Really disappointing, as I've had to resort to using `az vm start` -> run -> `az vm deallocate` to use an on-demand powerful runner.

0: https://github.com/github/roadmap/issues/161

1: https://github.com/github/roadmap/issues/95 (note: added `ga` `ae` and removed `beta` `cloud` labels on Oct 13, 2020 ; the previous text: https://web.archive.org/web/20200731200411/https://github.co... )

As a former CircleCI customer (my new employer uses Gitlab) I can highly recommend them. They make that issue so easy. You can even request GPU machines and it all works really well.

Why are you a former customer?

They said that their new employer uses Gitlab. The link in the OP describes that before today you couldn't use both at the same time.

I moved job.

I'm a bit biased as one of the founders of BuildJet, but we solve this exact issue.

BuildJet for GitHub Actions, plugs elegantly into GitHub Actions. With 1-line change in your config, you get 2x speed for half of GitHub's price.

Check it out @ https://buildjet.com/for-github-actions

Quick question, why does every startup on earth have google as a customer? Shouldn't a company of this size have its own solutions and programs?

This is in no way a deg against your project, its just a general question .

I imagine non-core-product teams at Google are encouraged to submit purchase requests for any tools they think would improve their processes instead of being constrained to existing solutions. They also could just be showing it because someone with an @google.com has a paid account, but I don't know for sure :)

I would think that it also brings the advantage of having tried the actual product in their own ecosystem, Google have a good overall insight into it in case they want to buy it - not sure if this is actually the case though.

Yeah, it's kind of a trope by now. However, we felt it was justified when Google Lighthouse wanted to use BuildJet.

Oh this is good. I couldn't find it in your documentation but how big are the disks on these VMs?

Oh, should probably add that to the docs. Anyway, they are 120 GB.

Absolutely. That's a huge jump over GitHub's tiny 14GB

We recently started using buildjet, and it has been nothing short of awesome. So I can highly recommend them.

Great market fit, runners are the worst part of GitHub Actions so I'm really glad to see a product enter this space as a drop-in replacement. Will definitely check this out for my pipelines.

As a long-time GitLab CI user, I do miss how the local circleci runner binary just worked. I am aware of gitlab-runner but it is a sick joke designed to mislead folks who just skim the docs into believing that they have a local execution story

Or, I guess a more conciliatory stance is: wow, folks must be using some pretty hello-world pipelines if `gitlab-runner exec` works for you

We provision our self-hosted runners via Terraform and GitLab's Helm chart. It's a relatively painless setup, but obviously not a few button clicks and commands

> a local execution story

I can see how "local" can have multiple meanings, but here I meant "as a developer on my laptop, can I have local docker run things the way GL is going to run things?"

I hear people say a lot "oh, I just use shell scripts, NBD" but as I said, I'm sure for hello-world setups which don't have any includes or take advantage of GLCI constructs that can work fine, but what rubs me the wrong way is that "gitlab-runner exec" doesn't say "just use shell scripts," it says "gitlab-runner exec - execute a build locally" and it for sure does not do that

Yeah this is a pain point for me as well, especially when developing the pipelines themselves. There's no good way to run it on my own machine, so I'm stuck pushing new commits to Gitlab over and over again and waiting for it to complete, or rather fail so I can troubleshoot the new error.

Depending on one's definition of "good," running GL locally in docker is (in my experience) painless, given sufficient disk space and probably RAM

But yes, your observation is my whole complaint: it is not _reasonable_ to ask a GLCI developer to run a local copy of GL, complete with any shared GLCI template repos, in a local docker container just to have local execution. Maybe I wouldn't complain about it so much had I not started with circleci so long ago and had such a "wow, this is amazing" followed by gitlab-runner's :troll_face: -- to say nothing of GitHub Actions just straight up ignoring that whole demographic and hoping https://github.com/nektos/act emulates enough to have people not notice the massive feature gap

unfortunately `act` is pretty bad :(

My go to workflow for workflows (ha) is forking a repo as a private fork and toying on it until I'm happy with the results

This thread makes me wonder if the root of the problem is actually the lack of a local runner. I hypothesize that it's the length of the feedback loop that's the real issue.

Even if we had a local runner, if it takes a ton of time to start and complete every step, it'd be almost as painful to debug as a remote runner taking the same time. On the other hand, if the cloud runner is ridiculously fast, and completes steps on the order of single digit seconds, it would be fairly painless to debug.

Not really. I mean yes my dev machine is faster than the CI runner, so things do run faster, but even assuming the CI runner was just as beefy and picked up the job immediately instead of taking 10ish seconds it's still the difference between

When running remotely: edit file > commit > push > switch to browser > browse to pipeline > repeat

Vs locally: edit file > run pipeline > repeat.

If you have access to the Kubernetes cluster or wherever your runner is running: put a sleep right before the error, execute into the running pod and debug it.

I like to do gitlab-runner exec docker … locally, but it doesn’t work with includes and you need to set up your own variables.

Ah, I see what you're saying. I've had to do some debugging in GitLab instead of local and it wasn't ideal. To prevent mucking with important stuff, I have a scratch project that's dedicated to testing things. It isn't perfect, but I've been able to replicate nearly every problem in the scratch project

Using built-in gitlab ci. It's definitely good enough for my ci needs. Setup was easy. Love having less tools involved in my day2day.

Some features seem to work incorrectly (ex. some combinations of branch filter rules + file changes rules). Or I misread the docs. For a free service it gives excellent value.

Circleci also good product. But having 1 less "thing" wins over most other considerations for me.

Funny, I was gonna say the same thing. But I also remembered GitHub now has built-in CI (Actions).

I wonder if Circle is struggling to maintain market share.

With all the built-in support for CI, I'm not sure how CircleCI is even operating anymore.

My last job used Gitlab as an external CI.

They offer a whole kitchen sink at this point and honestly it's not great.

I really like GitLab's CI. Actions is probably winning the war, though.

GitLab CI can launch multiple pipelines on the same push/trigger (use separate files, like GH Actions, etc), but even after using it for I don't even know how many years I'm still struggling with setting it up in a nice way.

Actions does seem to be winning, but having used both extensively I'm convinced that it's on name recognition alone (with pricing being a second). Gitlab CI is my favorite of the many I've tried (gitlab, circle, travis, github), Actions is probably my least preferred. It gets the job done but there are always a lot of actions-specific stuff for every job, whereas with most of the others they're relatively portable. Actions feels like it was designed with lock-in as a primary goal.

We're using gitlab with (on-premise) jenkins. It seems just much more capable (and if we choose to switch away from gitlab it won't matter)

Reply on news.ycombinator.com