Live data from Hacker News

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

twitter.com

61–70 of 133 posts

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

#61
post #56
post #35

Outside of work, I'm a very sporadic coder. On some side-projects where I'm using Actions, I'll have an inspired few days of progress followed by completely idle weeks/months/quarters. Losing free Actions doesn't particularly bother me, and I have no issue with paying what is most likely a negligible amount, but I don't really want to have a credit card on file which could be charged some unbounded amount if somebody…

There are several “virtual credit card” providers that allow you to generate additional cards, set limit on them like amounts and who can charge the CC. The availability varies per geography.

The problem with that is you might still get a huge bill if something goes wrong, then they try to charge it to your card at the end of the day/week/month/whatever, and it fails.

Now you still owe them the money, but haven't paid, so they tell you to pay on another card. If you refuse, they start debt collection against you and you could end up with your credit rating being affected, and maybe court cases and so on.

I want give the company an amount of money, then know that it's run out and I have to pay for more. You can set monthly limits (https://github.com/settings/billing/budgets), but if you are like me and have personal projects that you work on for a week or two a few times a year, that doesn't really work.

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

#63
post #33

1. Announce price increase generating bad publicity. 2. Kill bad publicity with blog pretending to be understanding and taking on feedback while "pausing" the increase. 3. Implement price increase a few months later when the bad publicity wave is over, and its old news so wont generate new headlines.

Nah, that doesn’t work when the substance of the change is this intense and has an actual effect on peoples’ bottom lines. If they wait a few months and try again, people will see their bills go up immediately and they’ll all get mad again. I don’t know what GH will do next, but if they try to do that, it will definitely backfire.

When they eventually roll it out (And they will, they always do), everyone will have had plenty of time to run the numbers and either come up with a plan, or just swallow the pill.

If you still complain in a few months then that's on you, because you've been warned.

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

#64

Earlier quoted context omitted.

I wonder if Microsoft will ever get that asking users before making changes can help them avoid looking bad in public. Maybe half of all clients I work with use GitHub Actions for CI (the rest basically all use Jenkins), most of those using Actions use self-hosted runners for performance and security reasons, almost all of them reached out to me asking how difficult it would be to move away from GitHub Actions yet co…

Fun thing is that almost every other CI as a service provider charges you in some shape or form for self hosted runners. CircleCI limits the number of self-hosted Job Running in parallel based on your plan and charges a fixed base fee per seat. So moving away from GHA will not make self-hosted runners free, they’ll move into a different pricing structure that may or may not be beneficial. And I think charging for sel…

I also think its fine and fair to charge for the general GHA infrastructure that one would also be using with self-hosted runners.

I suspect that they weren't looking to make money off of those charges, but rather use that as a forcing function to push more usage of their managed runner (which are higher margin) which didn't work out. Rather than everyone saying "damn that makes alternatives financially unattactive", a good chunk of the feedback was "sure I'll pay those charges as long as I don't have to use the shitty managed runners".

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

#65

Earlier quoted context omitted.

I wonder if Microsoft will ever get that asking users before making changes can help them avoid looking bad in public. Maybe half of all clients I work with use GitHub Actions for CI (the rest basically all use Jenkins), most of those using Actions use self-hosted runners for performance and security reasons, almost all of them reached out to me asking how difficult it would be to move away from GitHub Actions yet co…

Fun thing is that almost every other CI as a service provider charges you in some shape or form for self hosted runners. CircleCI limits the number of self-hosted Job Running in parallel based on your plan and charges a fixed base fee per seat. So moving away from GHA will not make self-hosted runners free, they’ll move into a different pricing structure that may or may not be beneficial. And I think charging for sel…

Depends if they are using another CI provider or running Jenkins themselves.

But also, Circle CI would be a known cost change. Right now, the only thing you know is that GitHub wants to start charging money. You have no idea what new pricing model they come up with.

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

#66

Earlier quoted context omitted.

Great! Who did you jump to ?

The most obvious "all-in-one" package is GitLab, if you have the hardware for it and don't mind bit of bloat but all the needed features in one package. Personally, for smaller scale projects that still require collaboration over the web, Gitea/Forgejo + Woodpecker CI has been a really simple, lightweight and easy to maintain solution.

I really love Gitlab CI. I don't miss managing my own Gitlab server but I definitely prefer their CI product to actions.

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

#67
post #25

> GitHub stated that it has canceled the price increase after reviewing developer feedback. It added that it will take time to listen to customers and partners. I get the feeling they got the feedback that their runners are not as indispensable to developers as they thought and realized they would lose a significant amount of users. Now if only they would listen to the feedback about windows 11 and their forced copil…

I feel like I could specify and vibe-code a CI workflow system that would be dramatically better (for a single organization’s workflow) than GitHub Actions. And hosting it would be barely more complex than hosting a GitHub Actions self-hosted runner.

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 :)

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

#68
post #41
post #26

Earlier quoted context omitted.

> We have real costs" Am i wrong or didn't they have a bug in the action runners that would basically cycle the CPU infinitely ? > https://github.com/actions/runner/issues/2380 > https://github.com/actions/runner/issues/3792 Didn't they take years to fix this ? Or its unrelated ?

They are talking about the cost to run the Actions control plane and the scheduler that is not executed on the runner itself.

They have all kinds of costs hosting GitHub, which is why there's per seat pricing for companies. If those prices are too low, they can always increase them. Charging on top of that per minute of using your own infrastructure felt greedy to me. And the fact that this was supposed to be tied to one of the lesser-maintained features of GitHub raised eyebrows on top of that.

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

#69
post #61
post #56

Earlier quoted context omitted.

There are several “virtual credit card” providers that allow you to generate additional cards, set limit on them like amounts and who can charge the CC. The availability varies per geography.

The problem with that is you might still get a huge bill if something goes wrong, then they try to charge it to your card at the end of the day/week/month/whatever, and it fails. Now you still owe them the money, but haven't paid, so they tell you to pay on another card. If you refuse, they start debt collection against you and you could end up with your credit rating being affected, and maybe court cases and so on.…

I know AWS, Azure, and GCP do allow for global caps. Azure has it with subscriptions for example. Not sure if it is only on recurring monthly basis. Having a pre-paid lump sum version available is nice but it would also open the door for denial of service if cash runs out. Maybe that is why it isn’t offered?

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

#70
post #25

> GitHub stated that it has canceled the price increase after reviewing developer feedback. It added that it will take time to listen to customers and partners. I get the feeling they got the feedback that their runners are not as indispensable to developers as they thought and realized they would lose a significant amount of users. Now if only they would listen to the feedback about windows 11 and their forced copil…

We jumped ship too. Forgejo has been amazing.
Post reply on HN