[donmcronald]

> Programmers do not like to pay for their tooling.

Eventually they’ll have to. Everything is trending to SaaS offerings and eventually we’ll be paying way, way more. The amount of money people spend on SaaS CI blows my mind and if that’s any indication the move to massively over priced SaaS tooling is inevitable.

[Silhouette]

I'm not sure I buy this argument. The one group of people who certainly can create good alternatives that don't rely on that lock-in effect are programmers, after all. It's their livelihoods and happiness we're talking about, not to mention often their own pockets feeding the SAAS beast in the case of small businesses and freelancers, so they have a lot of incentives to do exactly that. And there are millions of them, many of whom already contribute freely to projects they find interesting anyway.

[novok]

The pricing of SaaS CI or any kind of advanced server infrastructure is engineering salaries saved, not raw AWS bills. It's completely B2B software and you could do very, very well with just 1000 corps as your customers.

[DistressedDrone]

SaaS CI is valuable because it's not seen as something a programmer could easily make by themselves, unlike the vast majority of SaaS offerings, a lot of which are more marketing than code (not that that's a bad thing, but don't ask the average programmer how highly they value marketing).

[vbezhenar]

May be I'm missing something, but CI looks like the thing that's trivially implemented by a few bash scripts. It won't be as pretty and as reliable compared to battle-tested service, but generally it'll work. I did that in the past and it worked pretty well for our uses.

[hrktb]

The most valuable part of CI where I work right now is it being run on a reference setup, with persisted builds and logs attached to each merge requests.

We are all supposed to run tests, coverage and benchmarking localy. The point in CI is to guarantee nobody cut corners and keep verifiable proof of good builds.

We could fulfil the same requirements with a hand made setup on a box somewhere uploading subsequent artefacts, but I am not sure we would be happier on any specific aspect. Even cost wise, setup and maintenance could non trivial compared to the amounts we're paying now.

[johannes1234321]

A few bash scripts work up to some size. For many projects at some time demands increase and you got longer test runs, which eventually require more machines and and different independent build steps (maybe you don't want to build the core libraries which are rarely touched for each commit of other parts etc.?) and at some point it breaks apart and you need something "proper" especially if you then also want to integrate test results with code review and track them from the single planning tool.