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

61–70 of 124 posts

Re: CircleCI Announces Support for Gitlab

#61

Post by inferiorhuman »

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/

I interviewed with Github recently (a pretty mediocre experience overall) and it seemed like they've fully committed to remote work. They don't even bother with on site onboarding anymore.

Re: CircleCI Announces Support for Gitlab

#62

Post by inferiorhuman »

Benjamin_Dobell wrote: post #60
forty wrote: post #55

Earlier quoted context omitted.

Overpaying remote workers compared to the local market is bad as it create distortion of local markets (on housing especially where local non remote workers cannot afford living where they work). (I'm a remote worker outside of the US and my personal interest would be to be paid more, but I don't believe it would be the general interest)

This line of reasoning doesn't consider equity, and the fact that people want to move - especially out of low socioeconomic areas. If you're paid a local wage, there's basically no way you'd ever be able to relocate to somewhere more expensive since selling your house wouldn't put a dent in the price of a home elsewhere.

Sure, but paying a high wage relative to the local prevailing wage is different than paying the same high wage everywhere. Part of the problem in the Bay Area is that tech companies distorted the local wages so dramatically.

Re: CircleCI Announces Support for Gitlab

#63

Post by mtlynch »

lflux wrote: post #43
mtlynch wrote: post #38

Earlier quoted context omitted.

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.

Oh, gotcha. You have CI for multiple architectures already and you want to add arm64? I was thinking it was brand new code you wanted to write, but I get why you wouldn't want to rewrite everything.

Re: CircleCI Announces Support for Gitlab

#64

Post by mtlynch »

pojzon wrote: post #42
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.

Yeah, I'd like to, but I found Gitlab's CI to be a substantial step down from Circle's CI product. I elaborated a bit more in another comment:

https://news.ycombinator.com/item?id=32242463

Re: CircleCI Announces Support for Gitlab

#65

Post by LukeShu »

AtNightWeCode wrote: post #23

How can a CI-service not support ANY GIT source? All this garbage surrounding GIT is just baffling.

As much as I want to agree with you, I get it:

- To avoid polling, you want to be able to register a webhook to be notified when pushes happen. You're going to need Git-servicet-specific parsing of the webhook payload, and you probably want to be able to speak a Git-host-specific API to automatically register that webhook to make it easy for users. (Falling back to polling would be good, but few do.)

- If you're a paid product, you definitely need to support private repos. You probably want to be able to speak a Git-service-specific API to set up the credentials to be able to do that `clone`; in GitHub parlance use the API to create a "deploy key", rather than requiring users to manually mint an SSH key, set up a bot account on the Git-service, add the SSH key to that account, and upload the SSH key to the CI-service. (Falling back to being able to provide a raw Git URL and credentials would be good, but few do.)

- To avoid confusing user-account permission mismatches, you probably want to piggy-back on the Git-service's user system; supporting "sign-on with X" and using the Git-service's "is admin of this Git repo" for allowing access to your the CI-service's admin interface for that repo.

- You want to be able to post statuses back to the Git-host. This takes a Git-service-specific API. (Falling back to letting the user provide their own script for posting statuses would be good, but few do.)

Re: CircleCI Announces Support for Gitlab

#66

Post by mtlynch »

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.

That's fine. I'm not trying to convince anyone that Gitlab is the messiah or anything. Someone just asked me why I align more philosophically with Gitlab than Github, so I explained what appeals to me personally.

If they don't align with your philosophy, that's cool too. You get to choose how that affects your choice of VCS/CI provider.

Re: CircleCI Announces Support for Gitlab

#68

Post by lflux »

mtlynch wrote: post #63
lflux wrote: post #43

Earlier quoted context omitted.

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.

Oh, gotcha. You have CI for multiple architectures already and you want to add arm64? I was thinking it was brand new code you wanted to write, but I get why you wouldn't want to rewrite everything.

Just on amd64 right now, we want to move to add support for arm64.

Sadly we adopted CircleCI early on and make heavy use of their support for multiple containers - if you specify a list of containers in a Docker job, it will execute the tests in the first container and connect the other containers as "data" containers (think redis, mysql et c) for use in tests.

Re: CircleCI Announces Support for Gitlab

#69

Post by dugab »

lflux wrote: post #43
mtlynch wrote: post #38

Earlier quoted context omitted.

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.

If you need services for your tests in CI, you might want to look at what Gitlab CI "services" https://docs.gitlab.com/ee/ci/services/

Re: CircleCI Announces Support for Gitlab

#70

Post by judge2020 »

jacooper wrote: post #53
thinkafterbef wrote: post #48

Earlier quoted context omitted.

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 :)
Post reply on HN