GitHub postponing the announced billing change for self-hosted GitHub Actions
91–100 of 133 posts
Re: GitHub postponing the announced billing change for self-hosted GitHub Actions
#92Earlier 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…
Re: GitHub postponing the announced billing change for self-hosted GitHub Actions
#931. 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.
Re: GitHub postponing the announced billing change for self-hosted GitHub Actions
#94My 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 f…
I believe this has been a CI/CD best practice for over a decade. Even in venerable Jenkins, this is one of the core principles when designing pipelines[0]: don't give in to the temptation to do fancy Groovy stuff, just use simple shell commands in steps, and you will be grateful to yourself several times years later.
[0] https://www.jenkins.io/doc/book/pipeline/pipeline-best-pract...
Re: GitHub postponing the announced billing change for self-hosted GitHub Actions
#95There's one thing I don't understand. Isn't GitHub action just "take a repo, do something with it, save something somewhere". So how is it different than writing a bash script that "clones the repo, do something with it, pushes the changes back"? If actions became paid feature, wouldn't that just generated myriads of show hn posts like "I recreated GitHub actions in xyz"?
This change is a very weird one. Because the teams that are capable of setting up their own runners have the means to easily jump ship to another CI platform and skip these fees altogether.
Re: GitHub postponing the announced billing change for self-hosted GitHub Actions
#961. 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.
If this is the case then they don't really understand developers at all. We'll complain in a few months just as much as we do now.
Re: GitHub postponing the announced billing change for self-hosted GitHub Actions
#97The utter rent-seeking audacity of charging by the minute for action runners you run on your own server ... Charge a flat fee per Action, sure. There is a tiny cost on GitHub's part associated with the API calls for starting and stopping, but if my build takes 8 hours on a self-hosted runner there is no more cost to GitHub than it taking 10 seconds. That's the whole point of self-hosted runners. Maybe there was more…
Re: GitHub postponing the announced billing change for self-hosted GitHub Actions
#98My 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 f…
> 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. I believe this has been a CI/CD best practice for over a decade. Even in venerable Jenkins, this is on…
Re: GitHub postponing the announced billing change for self-hosted GitHub Actions
#99Re: GitHub postponing the announced billing change for self-hosted GitHub Actions
#100My 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 f…