I guess it's the AI driven approach. These things, critical infra, are always done better with a few eyes in it.. introducing irresponsible ideas of "I'll just remake it with Claude without knowing the underlying infra" can hit a few nerves, also add a few lower level bugs, exploits etc.
I don't think it's fair for the downvoted but I think it's worth discussing where we draw the line.
Edit: I think AI is a tool not a replacement.
My actual point is that GitHub Actions is kind of an unusual product. Many big cloud things solve what seems to be a simple problem but the actual requirements are much harder than they might appear, and replacing them well wouldn’t be very complex. But IMO GitHub Actions in particular is a bunch of complexity that does not actually solve the problem that needs solving very well; a small bespoke solution would actually be better.
The stack would be:
Postgres, as a job queue and job status tracker. The entire control plane state lives in here. Even in a fairly large org, the transaction rate would be very, very low.
An ingestion agent. Monitors the repository for pushes and PRs.
A job agent. This runs a in a sandbox and gets the inputs from GitHub and runs what is effectively a workflow step. It doesn’t get any secrets — everything it wants to do is either accomplished in the form of JSON output, blob output, or an org-specific API for doing things that don’t fit the JSON output model.
A thing to handle results. This is a simple service, connected to the database, that consumes the JSON job results and does whatever is needed (which would mostly consist of commenting on PRs or updating a CI status dashboard). For CD workflows, the build artifacts would be sent to whatever registry they go to.
A configuration system, which would be some files somewhere, maybe in a git repository that is not the repository that CI is being done on. (GitHub’s model of Actions config being in-band in the repository is IMO entirely wrong.)
And that’s about it.
I’m not suggesting that I could duplicate the GitHub Actions in a weekend. But I wouldn’t want to. This would be single-tenant, and it would support exactly the features that the organization actually uses. Heck, even par-for-the-course things like SSO aren’t needed because the entire system would have no users per se :)