Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CircleCI Announces Support for Gitlab

circleci.com

Post reply on HN
Print view View original

41–50 of 124 posts

Re: CircleCI Announces Support for Gitlab

#41

Post by soneca »

mtlynch wrote: post #30
hawaiianbrah wrote: post #26

Earlier quoted context omitted.

GitHub also promotes remote work. Most of the company is remote and will always be remote.

That's fair, but I think Gitlab promotes it more strongly. They're 100% remote, and they publish guides teaching other companies how to replicate their remote-first setup: https://about.gitlab.com/company/culture/all-remote/guide/

Gitlab advocates for paying local salaries. That’s actually against my “philosophy“ as you put it, as it is against my direct interest, being a non-US based software developer.

Their way to promote remote work is, ironically, hurtful to my prospects as a remote worker.

Re: CircleCI Announces Support for Gitlab

#42

Post by pojzon »

mtlynch wrote: post #6

I've been a CircleCI customer for 3 years. I'm interested in moving from Github to Gitlab, as I'm philosophically more aligned with Gitlab. I tried out CircleCI's Gitlab integration a few weeks ago during the public beta, and it felt like CircleCI was really phoning it in. The instructions led me down paths where the product would just break. It told me to connect CircleCI to Gitlab through OAuth, and then my first b…

In case you consider Gitlab as an e2e solution or devops platform as a whole:

Why would you need CircleCI?

Gitlab can work as a full CICD platform.

Re: CircleCI Announces Support for Gitlab

#43

Post by lflux »

mtlynch wrote: post #38
lflux wrote: post #35

Still no support for arm64 docker executors after years of asking for it.

Can't you run Docker on an arm64 machine executor? https://circleci.com/docs/using-arm I know it's not as convenient as being able to use a docker executor directly, but it seems straightforward to work around.

I can and it would require porting my entire CI workflow to machine. We use a lot of docker-executor specific stuff, and if I'm going to spend the time to port several thousand lines of CI config, I can just port it to a different CI platform instead.

Re: CircleCI Announces Support for Gitlab

#44

Post by Dracophoenix »

robertlagrant wrote: post #40
judge2020 wrote: post #22

Earlier quoted context omitted.

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

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?

Re: CircleCI Announces Support for Gitlab

#45

Post by pojzon »

mr337 wrote: post #21
zamalek wrote: post #14

Earlier quoted context omitted.

We recently moved off of Circle CI to self-hosted GitHub Actions runners. It is ridiculously expensive: our solution is in the region of 27x cheaper.

I've seen some projects where the Circle CI costs are more expensive than hosting.

Datadog+CircleCI+Dynatrace and your project costs more than fee full time ppl working on them.

But for some companies paying extra to be able to blame someone is crucial.

Re: CircleCI Announces Support for Gitlab

#46

Post by mdaniel »

goodoldneon wrote: post #37
mdaniel wrote: post #31

Earlier quoted context omitted.

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

Re: CircleCI Announces Support for Gitlab

#47

Post by nickstinemates »

sureglymop wrote: post #36
pid_0 wrote: post #10

Who even uses external CIs anymore? GitHub and gitlab ones are great otherwise you have plenty you can deploy yourself.

They're "great"? Really? Imo the only sane thing is to write CI/CD pipelines in a scripting language like sh. That way it is portable and doesn't depend on one platform. Gitlab CI supports "include" but not for scripts, just for templates. It's hard to have a centralised repository of scripts and include ones to use in a pipeline. I just don't understand why CI/CD couldn't just be in sh...

It's funny I started my career building exactly what you suggest. Even in shell. Before adopting Hudson (now Jenkins) and the like.

Bespoke CI/CD solutions are great, especially if you're the author and tailor it to the business, for a certain size and class of use case.

As a business though, it's hardly ever worth the investment/maintenance and ongoing operational cost vs. just externalizing it and dealing with the consequences unless it is your business or a fundamental part of how your business is delivered. Thus, generic (but extensible) solutions are the happy medium.

Re: CircleCI Announces Support for Gitlab

#48

Post by thinkafterbef »

judge2020 wrote: post #22
mtlynch wrote: post #5

Earlier quoted context omitted.

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

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

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

Re: CircleCI Announces Support for Gitlab

#49

Post by nickstinemates »

pojzon wrote: post #45
mr337 wrote: post #21

Earlier quoted context omitted.

I've seen some projects where the Circle CI costs are more expensive than hosting.

Datadog+CircleCI+Dynatrace and your project costs more than fee full time ppl working on them. But for some companies paying extra to be able to blame someone is crucial.

(sorry to sidetrack) but what is the usecase of deploying both dynatrace and datadog in the same environment? I don't think I have ever heard of this combination before.

Re: CircleCI Announces Support for Gitlab

#50

Post by CSMastermind »

soneca wrote: post #41
mtlynch wrote: post #30

Earlier quoted context omitted.

That's fair, but I think Gitlab promotes it more strongly. They're 100% remote, and they publish guides teaching other companies how to replicate their remote-first setup: https://about.gitlab.com/company/culture/all-remote/guide/

Gitlab advocates for paying local salaries. That’s actually against my “philosophy“ as you put it, as it is against my direct interest, being a non-US based software developer. Their way to promote remote work is, ironically, hurtful to my prospects as a remote worker.

Yeah location based salary discrimination is one of the biggest issues in our industry in my opinion. I'm really hoping that the move to more remote-forward working cultures spurred by Covid will lead to this being corrected.
Post reply on HN