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

71–80 of 124 posts

Re: CircleCI Announces Support for Gitlab

#71

Post by ok_dad »

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.

Gitlab should just offer to cover moving expenses for employees 1 time per X years, then even the poorest-paid person working there would have that freedom (aside from any immigration concerns). I don't think it's in their best financial interests, but would cost maybe 10k at most and whatever the additional salary per year is and garner more support for their "local pay scale" strategy.

Re: CircleCI Announces Support for Gitlab

#72

Post by criley2 »

inferiorhuman wrote: post #62
Benjamin_Dobell wrote: post #60

Earlier quoted context omitted.

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.

People are going to min-max whatever system you offer. If you don't pay equally and you adjust for cost of living, people are likely going to go for high CoL locations and make you pay the most. If you don't adjust for CoL, you'll likely see your devs leave high CoL areas for lower ones. While you might be "overpaying" them according to their chosen CoL, you're likely underpaying what the high CoL would have demanded.

It seems counter-intuitive but I imagine that not doing CoL adjustments actually lowers total payroll.

Re: CircleCI Announces Support for Gitlab

#73

Post by mappu »

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

You may be interested in Laminar CI.

Re: CircleCI Announces Support for Gitlab

#74

Post by thinkafterbef »

stusmall wrote: post #59
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

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.

Re: CircleCI Announces Support for Gitlab

#75

Post by olalonde »

forty wrote: post #55
soneca wrote: post #41

Earlier quoted context omitted.

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.

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 seems like a variation on the fixed pie fallacy. It's absolutely in the general interest for more people to get paid more. How do you expect poorer markets to catch up with richer ones if you believe that it is bad for people in such markets to get paid more? Nonsense.

Re: CircleCI Announces Support for Gitlab

#76

Post by thinkafterbef »

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 .

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

Re: CircleCI Announces Support for Gitlab

#77

Post by Volundr »

mdaniel wrote: post #46
goodoldneon wrote: post #37

Earlier quoted context omitted.

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

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.

Re: CircleCI Announces Support for Gitlab

#78

Post by mdaniel »

Volundr wrote: post #77
mdaniel wrote: post #46

Earlier quoted context omitted.

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

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

Re: CircleCI Announces Support for Gitlab

#79

Post by bschwindHN »

dijit wrote: post #57
IfOnlyYouKnew wrote: post #54

Earlier quoted context omitted.

I feel GitHub is the best thing that ever happened to the Open Source Community. Before, it was freshmeat and, for collaboration, arbitrary mailing lists each enforcing their same "standards" to send in patches. I can only assume the process was sometimes smooth, sometimes terrible. In any case: I never did it. In the GitHub era, I have regularly made pull requests. Small ones on a maybe weekly basis, larger ones twi…

Github is social media for code; which is great for discovering things or fly-by addons.. Social media in the workplace is not as great, ask anyone using facebooks communication platform: https://www.workplace.com I much prefer working with gitlab as a product 9hours a day on internal systems.

Github is nowhere close to "social media in the workplace".

I use github every day and the only time I interact with people I don't know is if I'm submitting a patch to another project I use. Comparing it to facebook workplace is weird.

Re: CircleCI Announces Support for Gitlab

#80

Post by inferiorhuman »

criley2 wrote: post #72
inferiorhuman wrote: post #62

Earlier quoted context omitted.

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.

People are going to min-max whatever system you offer. If you don't pay equally and you adjust for cost of living, people are likely going to go for high CoL locations and make you pay the most. If you don't adjust for CoL, you'll likely see your devs leave high CoL areas for lower ones. While you might be "overpaying" them according to their chosen CoL, you're likely underpaying what the high CoL would have demanded…

> It seems counter-intuitive but I imagine that not doing CoL adjustments actually lowers total payroll.

That's not the problem that forty was talking about. The issue is that when you drop a ton of employees in an area whose wages are well beyond the norm you create larger societal problems.

Post reply on HN