But it is not for hardware you own. It is for the use of GutHubs coordinators, which they have been donating the use of to you for free. They have now decided that that service is something they are going to charge for. Your objection to GitHub "extracting usage-based rent from me" seems to ignore that you have been getting usage of their hardware for free up to now.

So, like I said, the question for you is whether that $140/month of service is worth that money to you, or can you find a better priced alternative, or build something that costs less yourself.

My guess is that once you think about this some more you will decide it is worth it, and probably spend some time trying to drive down your minutes/month a bit. But at $140 a month, how much time is that worth investing?

I get the frustration. And I’m no GitHub apologist either. But you’re not being charged for hardware you own. You’re being charged for the services surrounding it (the action runner/executor binary you didn’t build, the orchestrator configurable in their DSL you write, the artefact and log retention you’re getting, the plug-n-play with your repo, etc). Whether or not you think that is a fair price is beside the point.

That value to you is apparently less than $140/mo. Find the number you’re comfortable with and then move away from GH Actions if it’s less than $140.

More than 10 years of running my own CI infra with Jenkins on top. In 2023 I gave up Jenkins and paid for BuildKite. It’s still my hardware. BuildKite just provides the “services” I described earlier. Yet I paid them a lot of money to provide their services for me on my own hardware. GH actions, even while free, was never an option for me. I don’t like how it feels.

This is probably bad for GitHub but framing it as “charging me for my hardware” misses the point entirely.

feels like a new generation is learning what life is like when microsoft has a lot of power. (tl;dr: they try to use it.)

It sounds like you'd be better off self-hosting Jenkins. The other issue with GHA is they cap all runs at 6 hours.

Despite what people say about "maintaining" Jenkins (whatever that means to them personally) - you can set it up in an IaaC way including the jobs. You can migrate/create jobs en masse via its API (I did this about 10 years ago for a large US company converting from what was then called TFS)

Somewhere around 0.00004$ probably.

Nice profit margin…

Exactly this. It’s not like they don’t have plenty of other fees and charges. What’s next, charging mil rates for webhook deliveries?

Is it polling the runner, or is the runner sending it progress?

Microsoft "suddenly" does not seem to want you to run your own CI, which is a key part of running your own SCM. And this decision miraculously happens the moment a lot of big orgs are looking at self-hosting a cost effective (because open source) near 1:1 alternative to GitHub (=Forgejo).

So they make CI a bit cheaper but a future migration to Forgejo harder.

In fact they could easily pull off some typical sleazy Microsoft bullshit and eventually make it a shit ton harder to migrate out of GitHub once you migrated back in.

The idea is that they let you stay locked in for free. They dissuade people from making their CI pipeline forge-agnostic by charging you if you if you take steps to not be dependent on them. This means they can keep charging in other areas, and keep people in GitHub so that it stays dominant. Dominance is something that can be used to keep people in the Microsoft ecosystem, keep GitHub as the place where code goes so they have training data for LLMs, and dominance can simply be cashed in down the line.

I don’t know if that’s actually why they’re doing this, but it sounds plausible.

If you make running your own runners as expensive as running on Github's runners on top of the cost of actually hosting the runners, then if you are currently on Github and not able to migrate off immediately, the price conscious decision is to migrate runners into Github. But then, its even harder if you ever decide to migrate your whole operation out.

Now, if you are already looking at migrating, its also potentially a kick in the butt to do it now. But if you aren’t, the path of least resistance—or at least, the path of least present recurring cost—is a path to a greater degree of lock-in.

Where does GitHub even make most of their money? Their compliance posture makes them a non-starter for any regulated industries (which is atypical for a Microsoft property, generally MS is the market leader for compliance in all of their products).

Representatives from the Dutch government recently had a chat with representatives from Forgejo because they are quite interested in migrating their SCM infrastructure from Github to Forgejo.

And trust me, they are running a lot of public and private repositories.

And there are many more orgs and govs throughout Europe doing similar things because there's a (growing) zeitgeist here that the Trump administration nor any American SaaS company can be trusted. This started, by the way, after Microsoft suspended the ICJ from using Microsoft 365 on orders from the White House.

> Having your commits refer ticket ID from system that no longer exists is royal PITA

just rewrite the short links in your front-end to point to the migrated issues/PRs. write a redirect rule for each migrated issue/PR, easy

hard-coded links in commit messages are annoying, you can redirect in the front-end too but locally you'd have to smudge/clean them on local checkout/commit

Democratic organization is a strike?

Where do you live that that seems like a bad idea?

Inclusivity and democratic governance of a project is a strike to you? Seems like perhaps your hat is showing...

Inclusive is strike 1?

What color are you?

I'm sure I can find a company that supports ethnostates if you need that for your next project.

Github being a single pane of glass for developers with a single login is pretty powerful. Github hosting the runners is also pretty useful, ask anyone who has had to actually manage/scale them what their opinion is about Jenkins is. Being a "Jenkins Farmer" is a thankless job that means a lot of on-call work to fix the build system in the middle of the night at 2am on a Sunday. Paying a small monthly fee is absolutely worth it to rescue the morale of your infra/platform/devops/sre team.

Nothing kills morale faster than wrenching on the unreliable piece of infrastructure everyone hates. Every time I see an alert in slack github is having issues with actions (again) all I think is, "I'm glad that isn't me" and go about my day

Yeah, it seems like a half-assed version of what Jenkins and other tools have been doing for ages. Not that Jenkins is some magical wonderful tool, but I still haven't found a reasonable way to test my actions outside of running them on real Github.

> Microsoft just conned a bunch more people with the same classic tech lock-in strategy they've always pursued, people are right to be pissed

People would be better served by not expecting anything different from Microsoft. As you say yourself, this is how they roll.

> The only learning to take away is never ever use anything from the big tech companies

Do you even believe in this yourself? Not being dependent on them would be a good start.

You can use webhooks to replace Github Actions: https://docs.github.com/en/webhooks/about-webhooks

Listen to webhooks for new commits + PRs, and then use the commit status API to push statuses: https://docs.github.com/en/rest/commits/statuses?apiVersion=...

We have internal integrations with GitHub webhooks that will hit our server to checkout a branch, run some compute, and then post a comment on the thread. Not sure if you can integrate something like that to help block a PR from being merged like Actions CI checks, but you can receive webhooks and make API calls for free (for now). Would definitely result in some extra overhead to implement outside of Actions for some tasks.

Ask them. I don’t set the policy at a company I don’t work at.

Their announcement gives a clue, and it’s to do with job orchestration.

Yep and the sky is blue and GitHub can charge for that too if they want to.

I don’t make policy at GitHub and I don’t work at GitHub so go ask GitHub why they charge for infrastructure costs like any other cloud service. It has to do with the queueing and assignment of jobs which is not free. Why do they charge per minute? I have no idea, maybe it was easiest to do that given the billing infrastructure they already have. Maybe they tried a million different ways and this was the most reasonable. Maybe it’s Microsoft and they’re giving us all the middle finger, who knows.

If you do it all, you can optimize the whole supply chain. Maybe you can put some expensive capacity you built to use and leverage it when otherwise impossible, etc.

Maybe it's bad business dealing with lots of non-standardized external hosts, and it drags you down.

Maybe people are abusing the free orchestration to do non-CI stuff and they're compromising legitimate users.

Look, I understand it's frustrating to some consumers. However, it's not irrational from GitHub's point of view.

What happens if I am, and now my developers suddenly start to produce changes much faster? Like, one developer now produces the volume of five.

Would you keep charging the same rate per head?

My projects are public anyway. If you respect the license and make the AI comply to valid license reuse, I'm game.