GitHub postponing the announced billing change for self-hosted GitHub Actions

Just as cloud agnosticism means you should be able to bootstrap your infra in different clouds, that also includes your ci/cd. As a greybeard sysadmin, my advice is to start separating your ci/cd from the platforms you run on.

https://www.slingacademy.com/article/git-post-receive-hook-a...

Another of my tricks is to tie in your containerization there too, system-nspawn is what I'm using at the moment, but it can apply to others.

My theory: Some manager's KPI is to increase the number of sold GitHub runner minutes. So they did some market research -- not enough to have a clear picture, but barely enough to be dangerous -- and found that some companies use self-hosted runners for cost reasons. So they deploy a two-pronged strategy: lower the cost of GitHub runners, and charge for the use of self-hosted runners, to incentivize switching.

This fails for several reasons that someone who actually uses the product might have intuited:

(a) For some use-cases, you can't switch to GitHub's runners. For us, it's a no-go for anything that touches our infrastructure.

(b) Switching CI providers isn't hard, we had to do it twice already. Granted, most of our CI logic is in a custom build script that you can run locally, and not in the proprietary YAML file. But to be honest, I'd recommend that sort of setup for any CI provider, as you always want the ability to debug things locally.

(c) GitHub Actions doesn't get the amount of love you'd expect from something billed as a "premium service". In fact, it often feels quite abandoned, barely kept working. Who knows what they're brewing internally, but they didn't coordinate this with a major feature announcement, and didn't rush to announce anything now that they got backlash, which leads me to believe they don't have anything major planned.

(d) Paying someone -- by the minute, no less -- to use my own infrastructure feels strange and greedy. GitHub has always had per-user pricing, which feels fair and predictable. If for some reason they need more money, they can always increase that price. The fact that they didn't do that leads me to believe this wasn't about cost per se. Hence the KPI theory I mentioned above: this wasn't well-coordinated with any bigger strategy.

We already pay for the “control plane” for GHA, though.

You might as well say that we should be paying per PR and Issue because, well, that part can’t just be free, you know?

That would be my guess, I know personally yesterday I finally setup Forgejo and today I plan to evaluate its runners or even just using a dedicated CI like woodpecker.

Not fully sure what I will do regarding any open source repo's yet, but at least anything private I am already in the process of moving away.

This was something I already wanted to do for privacy concerns (especially possibility using private repo's to train AI) so this was just the push I needed.

How do you pay? Because the basic organization plan is free and gives access to GHA and includes 2000 free minutes.

If you upgrade the plan, you get more minutes for free - which can be consumed by the cost for free runners. They haven't specified at which rate a self-hosted runner consumes the free minutes, but at least for us, the change will largely consume free minutes.

> You might as well say that we should be paying per PR and Issue because, well, that part can’t just be free, you know?

You're misrepresenting what I said. I said, I'm fine with this for these reasons. It's a statement about me, not about what you should do nor what you should consider fine.

I pay (quite a bit) for GH because I do receive a service that's worth it, at least for now. And I'd rather see that GHA is something that makes them money than become something that is second-rate and lingers, just as it did before they made this announcement.