[suryao]

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.

[franklyworks]

Any thoughts on what to extent GitHub is subsidizing OSS development with its CI?

This feels like one of the big issues that OSS projects might face when migrating to an alternative.

What might a less GitHub centric CI ecosystem look like for OSS community?

[suryao]

Small to mid sized OSS projects benefit heavily from this. There is a size beyond which the free runner sizes become insufficient, but the assumption is that some form of monetization is figured out by that time. For example, we have a lot of OSS projects using WarpBuild because performance and fast CI is important for productivity.

Without GitHub's free CI for public repos, the small projects and indies will get hit the hardest imo.

However, I do not know hard numbers to quantify the impact.