GitHub Action Runners and the Personal Repository

A while back I made the decision to try and standardize on a single CI/CD/Git platform, and at the time GitHub made the most sense. I've spent years bouncing between GitLab, Gitea, Bitbucket, and GitHub and probably lost dozens of projects in the switches over the years. So, standardizing on "the biggest" was the easy move.

For most things, standardizing has been the right move. I've kept up a collection of repositories, public and private, under my personal namespace. Some of these will yet become public once they're a little further along, but they all operate with the same features and rules that GitHub provides. Ultimately there's been one issue that's been bothering me for a while, but a second issue has reared its head today and it's a problem.

Branch Protection Rules

The first issue, this is such a simple but mandatory feature to me. It's the first thing I want to set up in a new project, and it's also the first sales pitch I hit in every new project.

I understand the theory, kind of, behind not enabling this for private personal repositories. If you're not actually shipping whatever you're writing with a proper CI/CD pipeline then perhaps this doesn't matter. Alternatively, maybe you can detect and prevent this from happening in some sort of CI/CD check and bail out. On the bright side, at least the big "Your main branch isn't protected!" warning on free organization repositories is gone.

Maybe it's a weird play on trying to get low-stakes repositories moved to public, as a way of getting users to share more code?

There's one more angle here though, that I think is important enough to warrant the feature being made available to everyone. AI Agents. I've seen it enough times in enterprise to know that sometimes, your Claude or GPT or whatever decides it can't read your guardrails anymore, and decides the best way to make a change is pushing it directly to your main branch. In these instances it was a problem for users who had admin access to the repository and the branch restrictions wouldn't have applied, but if it happened multiple times among a small pool of admins how many times would it have applied without those restrictions in place?

As someone who tries to keep a proper PR trail, even on personal projects, I'd argue that branch protection is the second most important feature private users don't get, and I've considered converting my personal repositories into a team-of-1 organization as a result.

Of course, I said "second most important", because...

User-Wide GitHub Action Runners

For this one, I can't think of a single reason why it should exist this way.

GitHub Actions, the job running interface for GitHub, doesn't support configuring a single runner for use across multiple personal projects. Instead, GitHub suggests creating a new runner for every repository you want to self-host a runner on.

This one is truly mind boggling. Runners per repository? Even in a world where it was acceptable to run one job at a time (it isn't), never need more than machine type for your actions (which isn't true), and only ran Actions on a subset of your projects (???) the overhead of maintaining multiple runners which are constantly checking for jobs to pick up and run could be one of the worst decisions in developer-focused products that I can think of. If there's one feature that's going to drive me to another migration away from GitHub, it's this one.

Or, you know, you could just create an organization and migrate all your repositories.

Influencing Developers

Maybe a developer who works on web-only projects, deploys manually, doesn't automate running tests, linting, or formatting in CI, doesn't use releases, and doesn't maintain a history of their projects doesn't care for these feature. In that world, maybe they don't mind these issues and don't see a problem with the free plan GitHub offers.

Or, cynically, maybe it's intentional to convert free users to paid users, and the one-user-team organizations are the intended use case once a user gets the basics under them. GitHub Education certainly supports this idea, letting users have access to "proper" tooling in their repositories while they're in school before dumping them back to the free tier and hoping they pay to maintain access. GitHub's plans to make users pay for using their own runners also reinforce this idea, and if/when the idea does come back it'll probably be the final push to move everything off to another service.

GitHub's claims of the backend services certainly makes sense, and operating anything at that scale comes with a collection of costs that you wouldn't expect until you start picking the service and its uptime apart. However, if the ability for users to use their own machines to run jobs against their own code is such a cost-prohibitive adventure, either shift more of the management onto the user (self-hosted Actions control plane?) or accept it as a cost of doing business as the de facto solution for hosted git operations. With revenue in 2022 being over $1 billion, or the rumoured $2 billion+ in 2024 investing in junior developers building solid foundational skills is surely worth it to a company that can see past their quarterly earnings. Especially today in the current environment of AI-everything replacing junior developers in the very pool of talent GitHub draws from for its engineers.

Concluding Thoughts

Gitea provides the simplest migration, as their actions claim to be mostly compatible with GitHub's format.

Forgejo I know nothing about, as it's burst onto the scene after I was last looking for replacements. However it also promises GitHub Actions-like support in its own Actions system. However, its main page gives me the same vibes as open source software sites that started to fall when GitHub started gaining popularity, and I can't put my finger on why.

GitLab's CI/CD pipeline has always been well supported, although I've been out of the ecosystem for a few years.

I've heard good things about CircleCI, and seem to recall pretty good GitHub integration. Their free plan seems to include everything a single developer would need, but this only addresses one of the two issues above.

Regardless, this is one space I'm not going to spin my own solution for.

And now, off to register 18 new runners to enable cross-platform testing and building for two different ongoing projects.