CircleCI Announces Support for Gitlab | Hacker News Reader

CircleCI Announces Support for Gitlab

circleci.com

175 pointsoctavianc120 comments

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 build immediately died asking for a personal access token.[0] I generated a PAT instead, and then CircleCI failed my build because it was provisioning an empty SSH private key.[1]

They had a channel for reporting bugs with the integration, but it doesn't create a real support ticket. Their feedback channel was just their public Canny feature request board. I submitted my feedback anyway, and they didn't respond for over two weeks, at which point the response was basically just, "Oh, we fixed a lot of bugs, so maybe we fixed yours. Can you delete everything and try again?"

[0] https://twitter.com/deliberatecoder/status/15430630495982714...

[1] https://circleci.canny.io/gitlab-vcs-experience-feedback/p/n...

What does it mean to be more philosophically aligned with one corporation vs another?

Maybe more philosophically aligned with the product, rather than the corporation behind it. Microsoft is slowly turning GitHub profiles into networking tools and the core SCM offering into a social media experience. GitLab is similar in some ways, but not quite as aggressive about it in my view.

Github has always had a social media aspect. Profiles, stars, feeds, followers have been there since early days. One of their tag lines was "social coding".

Whenever I want to view my private repos, I have to navigate a painful UI first.

I'm given badges, and other gamification crap.

Then again, when I publish my projects I tend to post them either here or on Reddit.

Maybe Microsoft, with some justice, wants a cut of the traffic?

I was kind of against this, until I realized the reason I even began programming was purely out of social need (to make a program for me and my friend). I don't really mind it anymore.

GitLab offers a free and open source self-hosted "community edition" and understands it to be in their strategic interests to continue with the open source offering. GitHub does not offer it and does not appear to believe that an open source self-hosted offering is in their best interests.

Supporting GitLab on those reasons alone, and choosing to pay for GitLab Enterprise Edition because they offer the Community Edition, is "philosophically aligned"

That the buyer believes in the same thing the company "believes" in.

Eg: GitLab has an open-core product and GitHub is owned by (evil?) Microsoft.

Also the company is incredibly open, with lots of its documentation and meetings done in public and available on YouTube. Pretty interesting.

I like many things Gitlab does: open-sources most of their product, publishes their documentation openly, promotes remote work.

I strongly dislike some of the things that Github does: suck up open-source code and re-sell it through Copilot, stifle competition by offering free services that their non-MS-owned competitors can't afford to offer.

I don't think either one is purely good or purely evil. Overall, I like both companies better than average, but I'd rather support Gitlab.

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.

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.

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.

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.

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

I don't really think you do. Even poor rural communities have working rich like doctors and lawyers. There are rich rural folk 5 hours from every city. Adding a developer here and there is just a new face of the same working rich, the top 1-2%.

In fact, concentrating developers in one place like SF is pretty clearly the far greater social evil than ~evenly dispersing them around the country and letting them live in states/cities that perhaps desperately need the benefits of highly trained skilled workers who will pay a ton of taxes.

I would say that packing most developers into SF and California is far worse for America than letting educated and productive workers find communities around the country, potentially growing tech industries all over. Likely far better for equity, diversity, tax outcomes, and social good. I really can't see any argument for packing them all in California and letting all the other states rot.

> I don't really think you do. Even poor rural communities have working rich like doctors and lawyers. There are rich rural folk 5 hours from every city. Adding a developer here and there is just a new face of the same working rich, the top 1-2%.

Those doctors and lawyers aren't getting paid big city salaries.

Sure, they are primary care providers making $110k or real estate attorneys making $120k, instead of $400k in private practice in a rich area or partner at the big firm making millions.

But most developers aren't making that either. I get that there are some few who are making $400k to millions, but the median developer pay in every software field according to the stack overflow survey is ~80k.

Your average small town doctor is likely out-earning your average developer, so I think it's a good comparison.

Well the examples I have seen here in France did not work out so well. There were large arrivals of rich, well paid Parisians to cities like Nantes and Bordeaux, and it completely messed the local housing market, forcing many people who were living there to leave the city because they couldn't afford the rent anymore. Of course it creates a lot of resentment and tensions.

To be fair, France and the US are very very different. When we talk about rural areas in the U.S., we're not talking about Bordeaux, one of the most famous and prestigious wine growing regions in the entire world, a literally world famous rural area beloved by the elite of dozens of nations.

We're talking about flyover country. The kind of place that rich Parisians would only ever fly over and would never for any reason consider actually going to.

We're also talking about having so much space that the idea that developers could mess up local housing markets is crazy! In the US, packing developers together ruins housing markets (see the SF housing market ruined by tech companies) and spreading them out across the other 49 states and ~thousand+ rural locations prevents most out-sized effects, except in a few prestigious places known for elite vacations.

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.

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.

It's much easier to catch up if you can compete on price to start with. Why would a company take a chance on a developer in a new location if they've got to pay just as much? Once there's a critical mass of employers hiring in my location, competition will raise salaries up to parity, but sharing the surplus is what incentivises that competition in the first place.

I am not competing on price. I compete o quality. In your analogy, I am someone who the company needs to “take a chance”, the company is risking hiring a worse employee because I don’t live in SF or the US. That’s not how I see it.

The pandemic made a lot of people realize they can hire remotely and be fine. Why should I share the surplus with the company? I am a good developer and I will negotiate to get a better pay. Why wouldn’t I?

> Why should I share the surplus with the company?

The whole premise of being employed is that you make more money for the company than they're paying you.

> I am a good developer and I will negotiate to get a better pay. Why wouldn’t I?

So why would you rule out companies that pay location-adjusted salaries? If they're the best offer on the table then you're shooting yourself in the foot.

I don’t understand your last comment.

I rule out precisely because they never were the best offer in the table for me. There are companies that do not pay location-adjusted salaries that pay better. I was able to get a job in those the last two times I switched jobs.

A worse offer is a worse offer, a better offer is a better offer. If Gitlab isn't making competitive offers then of course take a better offer elsewhere, but what matters is the bottom line, not the method they used to come up with it.

> Why would a company take a chance on a developer in a new location if they've got to pay just as much?

They're not taking a chance on location. Location is irrelevant to the job.

Patently untrue. Setting up accounting in a new country may be a huge effort for the company.

The timezone alone may rule out a location.

Culture is closely aligned with location, and every company cares about "cultural fit" (while pledging to support diversity, of course) for better or worse.

Misaligned holidays, internet connection quality, even power supply disruptions... and so many things are directly affected by location.

How can someone think location is irrelevant?!?!

That's all true but besides the point. Paying a developer less because they have bad Internet connection quality, lack availability or because they incur more administrative costs makes sense. Those are all things that can affect their work performance or cost. Paying a developer based on their cost of living or based on what their neighbors are earning is nonsense.

> Paying a developer based on their cost of living or based on what their neighbors are earning is nonsense.

I agree it "looks" like nonsense... but it's not. It's reality. Different countries, even neighbouring countries, can have completely different salaries while doing the same thing... and things can cost completely differently too... Just check the border between the USA and Mexico.

Take the extra cash and go on to invest in new housing?

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.

That’s fine too. I just not trying to convince you of anything. You said you like Gitlab because they strongly promote remote work. I said I don’t like because they promote local salaries. That’s it, I wasn’t asking for your permission to think different than you, I was just posting a different point of view.

IMO it's better for our long-term interest if companies can pay what the market will bear. For now splitting the surplus is win-win; as remote work takes off then there wil be more competition and salaries will rise. Growing the pie is better than asking SV employers to overpay on some point of principle.

What? I should not negotiate a better salary with a company on the belief that, in the long term, it will be better for… who? Overpay? How can I be overpaid if the company agrees to pay? Should I be more humble? Should I give up some part of my salary so the company can have more money in their budget? Which pie am I growing by not taking my part? Whose pie?

That’s just silly

You should negotiate the best salary you can. What you shouldn't do is refuse to work for a company that's offering a better package than your current company out of some kind of principle because that company is also offering even better packages to employees somewhere else. Which is what you seemed to be advocating.

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.

GitHub has been fully committed to remote work for years before the pandemic. I suspect they’ll bring back on site onboarding at some point, but maybe not. Sorry to hear your interview experience was mediocre. They’ve been tweaking it, and not for the better in my opinion.

The co-pilot concern I get. I think the root of the problem is that everybody seems to have almost signed away their copyright to GitHub as part of their terms of service: https://fossa.com/blog/analyzing-legal-implications-github-c... "If you look at the GitHub Terms of Service, no matter what license you use, you give GitHub the right to host your code and to use your code to improve their products and features"... yeesh

I don't really agree with the concern that they "stifle competition by offering free services that their non-MS-owned competitors can't afford to offer". GitLab is clearly able to differentiate with with their terms of service, as evidenced by your and others' comments here. I don't fault the vast majority of FOSS developers, especially those using permissive MIT-style licenses, for favoring cost-efficiency over control. It's good to have both options.

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 twice a year or so.

I feel confident in the estimate that the number of contributors has grown by at least an order of magnitude, and that GitHub was a significant factor in this development.

Gitlab, meanwhile, started out as so obvious a clone their CSS still had classes named "gh-large-..." months after launch. Then, they would frequently have the audacity to complain when GitHub copied some minor feature they had first implemented.

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.

> Stifle competition by offering free services that their non-MS-owned competitors can't afford to offer.

This is quite absurd complaint, is it not?

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.

Can Gitlab CI use CircleCI workflows? There's less risk in just changing your VCS platform, rather than both your VCS and CI/CD at once, especially if you have to rewrite all your workflows.

Obviously something like Dagger[1] solves this, but I don't know how widely used that is at this point.

[1] https://dagger.io/

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

> But if I'm paying a company to manage CI, I don't want to provision my own hardware infrastructure

If you provision your own gitlab-runner, you don’t pay gitlab anymore for runner minutes. You can also split workloads between runners through tags.

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

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.

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.

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.

My last job used Gitlab as an external CI.

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.

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

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)

As an ex-CircleCI employee, this is really exciting because it marks a pretty significant milestone in a particular internal effort. Very much looking forward to what comes after this.

This might strike some as a weird event (Gitlab already has CI/CD!), but it _was_ highly requested and is (probably) of other similar things coming to fruition!

+1, also ex-CircleCI employee.

(high-five!)

Gitea next please! It would be awesome if Circle CI supports Gitea, which is in need of such an advanced CI/CD provider.

TIL CircleCI didn't support GitLab. I'm surprised it took them this long.

It's been their most requested feature for a long time:

https://circleci.canny.io/cloud-feature-requests?sort=top

I just tried out the AWS offering for CI/CD (CodePipeline/CodeBuild) and was disappointed with time-from-commit-to-deploy (to ECS, although it's the launch/build time I'm primarily concerned with here). It appears to waste 1-3 minutes on just queueing and provisioning a new VM to do the build. It's highly variable, too.

The main tradeoff (if the cost difference is insignificant) between this and a third party service like e.g. CircleCI appears to be between:

a) security (another service that can be comprised - with the implicit capability to instantly deploy something that owns your service)

and

b) latency/performance (CircleCI consistently starts builds within a few seconds)

How do you think about these things?

Given AWS has lambda, no fundamental reason starting workers should be slow.

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

I would guess it falls into the "what assumptions does the runner make?" followed closely by "there is no standard for what env-var contains: the current branch, the commit sha, the commit message, the current pipeline identifier, ..." and a bazillion other bits of contextual information

Made worse by: ok, fine, you magically have `eval $(git set-env-from-commit HEAD)`, now how do you report those run results back to the upstream UI, since there is for sure no standard for that

I doubt there was a problem cloning GitLab-hosted repos on CircleCI before this announcement. But there are plenty of non-Git things that these hosts do; pull requests, status checks, etc. I am guessing that "support for ..." entails all of those extras.

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

FWIW the first two are solved by git without any service.

Git can set up a post receive hook, which could do the triggering.

SSH key auth is a thing as part of Git+SSH.

Sure I couldn't set this with e.g. GitLab without them supporting GitLab, but if I'm self-hosting a git service, this seems like a fine solution.

Because the integration is entirely built on webhooks and each Git hosting provider has their own.

You would be surprised at how little of the code in a CI product, like CircleCI, deals with git. On the other hand, there is a lot of code required to integrate with the VCS - authn, authz, webhooks, commit-status, etc.

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

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.

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

Dynatrace apm is simplier to use than datadog. That was the only reason.

Also it was to show that some ppl dont understand the offering of products they use.

We were evaluating CircleCI at work (wanting to move on from Jenkins) and ended up going with GitHub Actions near launch as it was a similar enough project but without needing another vendor involved. We have had some kinks but GHA works well for us now with a substantial spend.

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.

I am proficient in sh/bash. I just think it's a little ridiculous since the actual main logic of something like gitlab ci is still lines of shell code... I don't have an issue learning the actual syntax/logic myself but it just feels wrong.