Hacker News new | ask | show | jobs
by juanbyrge 1501 days ago
I am surprised to see that GitHub staff are still working on GitHub Actions. It's hard to tell because it's been almost two years and it's still not possible to have a self-hosted GitHub Actions runner on Mac M1: https://github.com/actions/runner/issues/805, even though the community has made PRs for it.
5 comments

Self-hosted runners at scale are a nightmare. Random failures all around, exit code is whatever it wants to be... you'd think with the runner code in the open all that could be fixed, but no, it's a very confusingly written MS C# codebase that has clearly grown over the years as TFS Pipelines. Even the GitHub developers get confused when they tried to implement ephemeral runners and then figured out the scheduler just pipelines new jobs to runners and drops them permanently (shows as "waiting for runner for 15-20 minutes, then cancelled to the user) if you kill the runner anyway. And the worst: The component failing most often is the scheduler, and that runs at GitHub. It feels like it was written by an intern. It doesn't even do FIFO. Old jobs generally wait _longer_. We also have stuck jobs all the time because the scheduler lost it. GitHub Premium Enterprise Support just keeps saying to contact them whenever it happens and they're "working on it". My team has been working on making this entire crap work for almost an entire year on and off, and things only got marginally better. To the point we'll be using the new hosted runners with fixed egress IP and custom sizes instead.

Good job, you filled a hole in your spec sheet with literal shit and then sold us the only alternative a year later when it is unfeasible to migrate away again ("but we have a large Microsoft contract" politics keep us from doing that anyway, but that aside).

GitHub Actions are extremely actively developed and from what I can tell quite strategic. However, the action team's acceptance for outside contributions across all their projects (runner, toolkit, actions) seems surprisingly low for a company that runs a "social" coding service.
This is seriously bizarre.

Arguably the world's leading CI/CD tool doesn't support iOS builds on M1.

But yet they can deliver 100+ far less fundamental features: https://github.blog/changelog/

You can do it by running your terminal in compatibility mode. I’ve been running our iOS CI pipeline on an M1 for almost a year flawlessly at this point and it’s blazing fast.
People use mac m1s as servers?
Mostly the Mac Mini to run CI workflows or build iOS and macOS applications.
Macs are the only way to build iOS apps. And the M1 macs are several times faster at this task than the old ones.