We're microsoft. We don't care. We don't have to care, we're microsoft. Lock in? Embrace, expand, extinguish? Anti-competive? Anti-trust? We don't care. We don't have to care. Pay taxes? We don't have to pay taxes ( https://www.propublica.org/article/irs-microsoft-audit-back-... ). We're ... etc. This is not new, not unexpected. This is ongoing. Nothing stops this because who wins elections? How do they pay for all t…
Pricing Changes for GitHub Actions
121–130 of 853 posts
Re: Pricing Changes for GitHub Actions
#122Earlier quoted context omitted.
I'm curious, what are you doing that has over 1000 hours a month of action runtime?
On ZeroFS [0] I am doing around 80 000 minutes a month. A lot of it is wasted in build time though, due to a lack of appropriate caching facilities with GitHub actions. [0] https://github.com/Barre/ZeroFS/tree/main/.github/workflows
Re: Pricing Changes for GitHub Actions
#123Re: Pricing Changes for GitHub Actions
#124hoping for some disruption here. gha is an absolutely horrid platform for anyone trying to build optimized workflows. so many bugs / rough edges that haven't been addressed for years, the hosted runners feel like decade old compute. missing all of the modern features (like dynamic pipelines) other providers offer. to top it all off, they round up to the nearest whole minute instead of billing for actual usage which i…
Earthly did not work out, and dagger had the problem of we support everything but but nothing is great
Re: Pricing Changes for GitHub Actions
#125The urge to move to Codeberg grows with every passing day.
Re: Pricing Changes for GitHub Actions
#126That makes me genuinely curious about the internal hosted vs. self-hosted usage ratio they're seeing. I'd have guessed the bulk of the cost/volume was on hosted, but clearly that can't be the case
GitHub charges too much for hosted runners. It's pretty straightforward to switch to another runner provider at literally half the cost of GitHub.
Re: Pricing Changes for GitHub Actions
#127Re: Pricing Changes for GitHub Actions
#128Everyone in this thread has gone absolutely insane. $5/month gets you 41 fucking _hours_ of continuous operation. If you're not utterly abusing the platform, this falls extremely below the threshold of caring. And if not, what the fuck are you even doing with all those hours? The new per-minute charge is less than one millisecond of engineer labor cost.
I think you significantly underestimate the number of CI minutes people are using in practice. (Which, yes, has implications for energy use/climate change too for sure). It doesn't look like i currently have access to the usage data on any of the lots-of-runners-lots-of-PRs projects I currently work on (which are still probably way less than some large companies).
Any "large companies" don't give a shit about things at this cost level. They spend more on the time it takes you to open the door. The number of CI minutes could be astronomical and it still wouldn't rate above the threshold of caring. The time people in this thread have spent wringing their hands is way more expensive.
Re: Pricing Changes for GitHub Actions
#1291. Self-hosting runners is still cheaper than not Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) remains the cheaper option.
2. Prefer larger runners If your workflow scales with the number of vCPUs, prefer larger runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.
For example, using actions-runner-controller with heavy jobs running on 1 vcpu runners is not a good idea. Instead, prefer a 2vcpu runner (say) if it runs the job ~2x faster.
3. Prefer faster runners All else being equal, prefer faster runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.
For example, if you're self-hosting on aws and using a t3g.medium runner, it's better to use a t4g.medium runner since the newer generation is faster, but not much more expensive.
4. Prefer fewer shards If you have a lot of shards for your jobs (example: tests on ~50 shards), consider reducing the number of shards and parallelizing the tests on fewer but larger runners.
5. Improve job performance This is not new advice, but it's now more important than ever because of the additional GitHub self-hosted runner tax.
6. Use GitHub hosted runners for very short jobs For linters and other very short jobs, it's better to use GitHub hosted runners.
Note: I make WarpBuild, where we provide github actions runner compute. Our compute is still cheaper than using github hosted runners (even with the $0.002/min tax) and our runners are optimized for high performance to minimize the number of mins consumed. I'm generally biased, but I think the points 1-6 apply irrespective of WarpBuild.
Re: Pricing Changes for GitHub Actions
#130I hate GH Action runners with a passion. They are slow, overpriced, and clearly held together with duct tape and chewing gum. WarpBuild, on the other hand, was a breeze to setup and provided faster runners and lower prices.
This is a really shitty move.
Hey GitHub, your Microsoft is showing...