Live data from Hacker News

Pricing Changes for GitHub Actions

resources.github.com

121–130 of 853 posts

Re: Pricing Changes for GitHub Actions

#121

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…

Those of us who have been writing it "Micro$oft" since the 90's can now say, "I told you so."

Re: Pricing Changes for GitHub Actions

#122
post #114

Earlier 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

I found that implementing a local cache on the runners has been helpful. Ingress/egress on local network is hella slow, especially when each build has ~10-20GB of artifacts to manage.

Re: Pricing Changes for GitHub Actions

#124

hoping 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…

Would also be interested in a better platform

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

#126
post #9
post #5

That 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.

They are not just more expensive, they are also slower. Last time I compared them, AWS ARM64 instances could easily run jobs 30% faster, for the same CPU/memory count, than those that GitHub offers.

Re: Pricing Changes for GitHub Actions

#128

Everyone 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).

> 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

#129
Here are the practical implications and considerations to optimize for cost, given the new pricing. These are generic and ensure you think through your workflows and runners before making any changes.

1. 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

#130
Ahh, so since GitHub is completely incompetent when it comes to managing a CI they are going to make it worse for everyone to get their cut.

I 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...

Post reply on HN