Live data from Hacker News

Pricing Changes for GitHub Actions

resources.github.com

601–610 of 853 posts

Re: Pricing Changes for GitHub Actions

#601

It is us, developers, who convinced our management to purchase GitHub Enterprise to be our forge. We didn't pay any heed to the values of software freedom. A closed source, proprietary software had good features. We saw that and convinced our management to purchase it. Never mind what cost it would impose in the future when the good software gets bad owners. Never mind that there were alternatives that were inferior…

GitHub isn’t even good, it’s just the mediocre default everybody uses. PRs were fantastic and the best thing ever - 15 years ago!

Re: Pricing Changes for GitHub Actions

#602
post #414

Earlier quoted context omitted.

And if you want any concurrency at all, you need 1 runner registration per concurrent job. And each runner needs its own user. And each runner requires a full and separate copy of the runner software, which is large (hundreds of megs) and self-updates.

You don't need your own user. The rest is correct. (Though you can hardlink the installation.) And you can disable self-update, though it does it by default.

Hard-linking and running concurrent self-updates, sounds like a recipe for disaster.

Re: Pricing Changes for GitHub Actions

#603

Earlier quoted context omitted.

Runners aren’t fragile, workflows are. The runner software they provide is solid and I’ve never had an issue with it after administering self-hosted GitHub actions runners for 4 years. 100s of thousands of runners have taken jobs, done the work, destroyed themselves, and been replaced with clean runners, all without a single issue with the runners themselves. Workflows on the other hand, they have problems. The whole…

it's not the runners, it's the orchestration service that's the problem been working to move all our workflows to self hosted, on demand ephemeral runners. was severely delayed to find out how slipshod the Actions Runner Service was, and had to redesign to handle out-of-order or plain missing webhook events. jobs would start running before a workflow_job event would be delivered we've got it now that we can detect a…

> before the status page updates

That’s not hard, the status page is updated manually, and they wait for support tickets to confirm an issue before they update the status page. (Users are a far better monitoring service than any automated product.)

Webhook deliveries do suffer sometimes, which sucks, but that’s not the fault of the Actions orchestration.

Re: Pricing Changes for GitHub Actions

#604
post #582

Earlier quoted context omitted.

It's not my money man. It's still fine.

That not-your-money is still going towards rewarding user-hostile decisions

No ethical consumption under capitalism. My phone has minerals in it mined under slave-like conditions.

I'm all for everyone going full Libra - we do it at my co-op - but it makes sense to me that venture funded companies would "play the game" and light investor money on fire because, first, who gives a shit, and second, the investors want you to do that anyway so they can find out as fast as possible if you're a unicorn.

At my co-op, I spend hours writing future proof code and integrating FOSS solutions that I hope will serve us forever. When I'm at a startup, I'm looking for the fastest, maybe cheapest solution. YC gave us 200k in AWS credit? Guess we're on AWS. Another company in the cohort is some LLM IDE ala cursor and gave us a year free? Sure, burn tokens their investors are paying for, more agents for me. Vercel offers us a year of free hosting? Great, I hate nextjs but Claude loves it so fuck it, we deploy a nextjs app on vercel and lock ourselves deep into that ecosystem. Our product may not look like this at all in a year so I may be rewriting it in Vue or whatever when the vercel bills start coming in. Doesn't matter.

Re: Pricing Changes for GitHub Actions

#605
post #594

Earlier quoted context omitted.

Even purely from an altruist perspective I’d argue scenario 2 makes more sense as the resulting money can be used to fund a lot more open-source contributions.

Could in theory is very different from what actually happens. In the end the purists approach results in better more productive software across even slightly longer timescales. That ultimately produces more value and thus a richer society than the kind of short term pump and dump schemes which SV is so fond of. Who captures that value is a different story than was that value created.

yeah, I think ~all of open-source-funding-history stands as evidence opposed to #2, a la https://xkcd.com/2347/

Re: Pricing Changes for GitHub Actions

#606

Earlier quoted context omitted.

Because they host the artifacts, logs, and schedule jobs which run on your runners, I assume.

Then why do they charge by the minute instead of gigabytes and number of events?

Ask them. I don’t set the policy at a company I don’t work at.

Their announcement gives a clue, and it’s to do with job orchestration.

Re: Pricing Changes for GitHub Actions

#607
post #414

Earlier quoted context omitted.

And if you want any concurrency at all, you need 1 runner registration per concurrent job. And each runner needs its own user. And each runner requires a full and separate copy of the runner software, which is large (hundreds of megs) and self-updates.

You don't need your own user. The rest is correct. (Though you can hardlink the installation.) And you can disable self-update, though it does it by default.

Ah right, I've forgotten because I'm using a multi-user strategy and a patched version of the runner at this point anyway. The config directory for each runner is normally based on its install path (insane), something like that?

Re: Pricing Changes for GitHub Actions

#608

Earlier quoted context omitted.

Because they host the artifacts, logs, and schedule jobs which run on your runners, I assume.

they charge you for artifacts and logs separately, already

Yep and the sky is blue and GitHub can charge for that too if they want to.

I don’t make policy at GitHub and I don’t work at GitHub so go ask GitHub why they charge for infrastructure costs like any other cloud service. It has to do with the queueing and assignment of jobs which is not free. Why do they charge per minute? I have no idea, maybe it was easiest to do that given the billing infrastructure they already have. Maybe they tried a million different ways and this was the most reasonable. Maybe it’s Microsoft and they’re giving us all the middle finger, who knows.

Re: Pricing Changes for GitHub Actions

#609
post #557

Earlier quoted context omitted.

Gitea. Gitlab (ish?).

Gitea scales really badly with large repos in my experience. Gitlab works a lot better mostly because you can just throw more hardware at it. This is with a pretty large git repo and a lot of daily commits.

On the other hand, gitlab is a memory hog. You need a big vm dedicated to it.

We were on codeberg for a couple years and it was fine.

Re: Pricing Changes for GitHub Actions

#610

Earlier quoted context omitted.

Am I right in assuming it’s not the amount of payment but the transition from $0 to paying a bill at all? I’m definitely sure it’s saving me more than $140 a month to have CI/CD running and I’m also sure I’d never break even on the opportunity cost of having someone write or set one up internally if someone else’s works - and this is the key - just as well. But investment in CI/CD is investing in future velocity. The…

This is not investment in CI/CD. I already did that, by buying and investing in my own hardware, my own workflows, my own caching solution. This is like if Dropbox started charging you money for the files you have stored on your backup hard drives.

Don’t give them any ideas! This is actually a standard enshittification.
Post reply on HN