Live data from Hacker News

Pricing Changes for GitHub Actions

resources.github.com

371–380 of 853 posts

Re: Pricing Changes for GitHub Actions

#371

My take as a cofounder of Shipfox, a company working on alternative GitHub Actions runners (same space as Depot, Blacksmith, Namespace). The price update itself wasn't very surprising. GitHub-hosted runners historically carried a significant premium given the underlying hardware, which isn't particularly well suited for CI workloads that are often CPU-intensive. Lowering prices there makes sense and better reflects r…

"That said, most teams don't self-host purely to save money"

I think most do. Or at least the infrastructure/compute costs are not coming from their own dept budget anymore ;)

Re: Pricing Changes for GitHub Actions

#372

This seems backwards. Why charge for me to run the thing myself instead of them?

Because they know Forgejo is starting to get attention from major players and thus becoming competitive, and hosting your own CI infrastructure will make completely moving away from GitHub all that easier - If you don't really care about the metadata all it pretty much takes is moving git repositories with their history. Or shortly summarized: lock in through pricing. Pretty sure this will explode straight in their f…

I don't think Forgejo is competitive in the markets GitHub makes most of their money from, nor does it seem Forgejo developers want it to be.

Re: Pricing Changes for GitHub Actions

#373
post #244

Earlier quoted context omitted.

With these changes, three things hold: 1. Services like blacksmith and WarpBuild (I'm the founder) are still cheaper than GitHub hosted runners, even after including the $0.002/min self-hosting tax. 2. The biggest lever for controlling costs now is reducing the number of minutes used in CI. Given how slow Github's runners are, or even the ones on AWS compared to our baremetal processor single core performance + nvme…

I checked the WarpBuild website and got excited because the header in the menu says you have macOS Intel runners, but then you click through and it doesn't seem to be so? Right now at my company our biggest complaint are macOS Intel runners from GitHub which somehow take 15+ minutes to provision and are the slowest of the bunch.

[deleted]

Re: Pricing Changes for GitHub Actions

#374

Earlier this year I priced out AWS's on-demand m7i.large instances at $0.002/minute [1]. GitHub's two-core costs $0.008/minute today so it was a nice savings. But it looks like this announcement doubles the self-hosted cost and reduces their two-core system pricing to $0.006/min. From this perspective this is a huge price jump, but self-hosting to save money can still work out. Honestly, GitHub Actions have been too…

Have you considered other options like woodpecker for example?

Re: Pricing Changes for GitHub Actions

#377

Zig's decision to ditch GitHub actions seems remarkably prescient, no?

yes ! i'm actually doing the same as i saw the safe_sleep.sh code on their runners ... insane story ...

Can you elaborate on what you're referring to? Sounds interesting.

Re: Pricing Changes for GitHub Actions

#378

Earlier quoted context omitted.

They have these now.

Only for public repos though - if you're in an org with private repositories you don't get access to them (yet).

You do, you just have to set them up at the organization level. Windows/Linux/macOS are all available.

Re: Pricing Changes for GitHub Actions

#379

Oh great. I finally get used to GitHub Actions after Travis CI shat the bed, and now I have to find something else. Thanks, enshittification.

What part of this is “enshittification”? It’s just a company starting to charge for a formerly free service. Hardly seems like that aggressive a move.

They're squeezing their customers after locking in to juice their margins, having become a monopoly/monopsony. This is the classic enshitificaton playbook.

Re: Pricing Changes for GitHub Actions

#380
post #321

Personally, I quite liked GitLab CI when I used it circa 2021-23. Just now I did a quick search and found this article^1 suggesting (even before this GH pricing change) Gitlab CI may be a better choice than Github Actions. 1. https://medium.com/@the_atomic_architect/github-vs-gitlab-20...

GitLab CI is quite good. Have been using it for several years.

I can't tolerate it.

The split between tag and branch pipelines seems like intentional obfuscation with no upsides (you can't build non-latest commit from a branch, and when you use a tag to select the commit, GitLab intentionally hides all branch-related info, and skips jobs that depend on branch names).

"CI components" are not really components, but copy-paste of YAML into global state. Merging of jobs merges objects but not arrays, making composition unreliable or impossible.

The `steps` are still unstable/experimental. Composing multiple steps either is a mess of appending lines of bash, or you have go all the way in the other direction and build layered Docker images.

I could go on all day. Programming in YAML is annoying, and GitLab is full of issues that make it even clunkier than it needs to be.

Post reply on HN