[MathiasPius]

Introducing a separate charge specifically targeting those of your customers who choose to self-host your hilariously fragile infrastructure is certainly a choice.. And one I assume is in no way tied to adoption/usage-based KPIs.

Of course, if you can just fence in your competition and charge admission, it'd be silly to invest time in building a superior product.

[kjuulh]

We've self-hosted github actions in the past, and self-hosting it doesn't help all that much with the fragile part. For github it is just as much triggering the actions as it is running them. ;) I hope the product gets some investment, because it has been unstable for such a long time, that on the inside it must be just the usual right now. GitHub has by far the worst uptime of any SaaS tools we use at the moment, and it isn't even close.

> Actions is down again, call Brent so he can fix it again...

[Fabricio20]

We self host the runners in our infrastructure and the builds are over 10x faster than relying on their cloud runners. It's crazy the performance you get from running runners on your own hardware instead of their shared CPU. Literally from ~8m build time on Gradle + Docker down to mere 15s of Gradle + Docker on self hosted CPUs.

[btown]

> call Brent so he can fix it again

Not sure if a Phoenix Project reference, but if it is, it's certainly in keeping with Github being as fragile as the company in the book!

[tracker1]

I tend to just rely on the platform installers, then write my own process scripts to handle the work beyond the runners. Lets me exercise most of the process without having to (re)run the ci/cd processes over and over, which can be cumbersome, and a pain when they do break.

The only self-hosted runners I've used have been for internalized deployments separate from the build or (pre)test processes.

Aside: I've come to rely on Deno heavily for a lot of my scripting needs since it lets me reference repository modules directly and not require a build/install step head of time... just write TypeScript and run.

[MathiasPius]

In 2023 I quoted a customer some 30 hours to deploy a Kubernetes cluster to Hetzner specifically to run self-hosted GitHub Actions Runners.

After 10-ish hours the cluster was operational. The remaining 18 (plus 30-something unbillable to satisfy my conscience) were spent trying and failing to diagnose an issue which is still unsolved to this day[1].

[1]: https://github.com/actions/runner-container-hooks/issues/113

[featherless]

This is absolutely bananas; for my own CI workflow I'll have to pay $140+/month now just to run my own hardware.

[hinkley]

Am I right in assuming it’s not the amount of payment but the transition from $0 to paying a bill at all?

I’m definitely sure it’s saving me more than $140 a month to have CI/CD running and I’m also sure I’d never break even on the opportunity cost of having someone write or set one up internally if someone else’s works - and this is the key - just as well.

But investment in CI/CD is investing in future velocity. The hours invested are paid for by hours saved. So if the outcome is brittle and requires oversight that savings drops or disappears.

[hedgehog]

I'm curious, what are you doing that has over 1000 hours a month of action runtime?

[nyrikki]

I resorted to a local forgejo + woodpecker-ci. Every time I am forced back to GitHub for some reason it confirms I made the right choice.

In my experience gitlab always felt clunky and overly complicated on the back end, but for my needs local forgejo is better than the cloud options.

[awestroke]

They still host all artefacts and logs for these self-hosted runs. Probably costs them a fair bit

[gz09]

They already charge for this separately (at least storage). Some compute cost may be justified but you'd wish that this change would come with some commitment of fixing bugs (many open for years) in their CI platform -- as opposed to investing all their resources in a (mostly inferior) LLM agent (copilot).

[featherless]

There's absolutely no way that the cost scales with the usage of my own hardware. I cannot fathom this change in any way or form. Livid.

[zahlman]

Meanwhile I'm just running `pytest`, `pyproject-build`, `twine` etc. at the command line....

(People seem to object to this comment. I genuinely do not understand why.)

[colechristensen]

You don't trust devs to run things, to have git hooks installed, to have a clean environment, to not have uncommitted changes, to not have a diverging environment on their laptop.

Actions let you test things in multiple environments, to test them with credentials against resources devs don't have access to, to do additional things like deploys, managing version numbers, on and on

With CI, especially pull requests, you can leave longer running tests for github to take care of verifying. You can run periodic tests once a day like an hour long smoke test.

CI is guard rails against common failure modes which turn requiring everyone to follow an evolving script into something automatic nobody needs to think about much

[pseudosavant]

It passes on my machine. YOLO!

[misnome]

Because you appear completely oblivious and deliberately naive about the entire purpose of CI.

[naikrovek]

Runners aren’t fragile, workflows are.

The runner software they provide is solid and I’ve never had an issue with it after administering self-hosted GitHub actions runners for 4 years. 100s of thousands of runners have taken jobs, done the work, destroyed themselves, and been replaced with clean runners, all without a single issue with the runners themselves.

Workflows on the other hand, they have problems. The whole design is a bit silly

[falsedan]

it's not the runners, it's the orchestration service that's the problem

been working to move all our workflows to self hosted, on demand ephemeral runners. was severely delayed to find out how slipshod the Actions Runner Service was, and had to redesign to handle out-of-order or plain missing webhook events. jobs would start running before a workflow_job event would be delivered

we've got it now that we can detect a GitHub Actions outage and let them know by opening a support ticket, before the status page updates