Live data from Hacker News

Pricing Changes for GitHub Actions

resources.github.com

291–300 of 853 posts

Re: Pricing Changes for GitHub Actions

#291

Introducing a separate charge specifically targeting those of your customers who choose to self-host your hilariously fragile infrastructure is certainly a choice.. And one I assume is in no way tied to adoption/usage-based KPIs. Of course, if you can just fence in your competition and charge admission, it'd be silly to invest time in building a superior product.

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 GitHub Actions outage and let them know by opening a support ticket, before the status page updates

Re: Pricing Changes for GitHub Actions

#292

Getting acquired by Microsoft is a death sentence for any product. The only variable is how long after acquisition before they gut it. It's almost never right away. GitHub was acquired 7 years ago, but it started showing symptoms perhaps 2 years ago. With this I think it's clear the wound was fatal. GitHub will stumble on for a few more years with ever-decreasing quality, before going the way of Skype. So, I guess we…

https://codeberg.org

Re: Pricing Changes for GitHub Actions

#294
post #114

Earlier quoted context omitted.

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

ZeroFS looks really good. I know a bit about this design space but hadn't run across ZeroFS yet. Do you do testing of the error recovery behavior (connectivity etc)?

This has been mostly manual testing for now. ZeroFS currently lacks automatic fault injection and proper crash tests, and it’s an area I plan to focus on.

SlateDB, the lower layer, already does DST as well as fault injection though.

Re: Pricing Changes for GitHub Actions

#295

Earlier quoted context omitted.

You don't trust devs to run things, to have git hooks installed, to have a clean environment, to not have uncommitted changes, to not have a diverging environment on their laptop. Actions let you test things in multiple environments, to test them with credentials against resources devs don't have access to, to do additional things like deploys, managing version numbers, on and on With CI, especially pull requests, yo…

> You don't trust devs to run things, to have git hooks installed, to have a clean environment, to not have uncommitted changes, to not have a diverging environment on their laptop. ... Is nobody in charge on the team? Or is it not enough that devs adhere to a coding standard, work to APIs etc. but you expect them to follow a common process to get there (as opposed to what makes them individually most productive)? >…

I think you could learn a lot about the other use cases if you asked some genuine questions and listened with intent

Re: Pricing Changes for GitHub Actions

#296

Earlier quoted context omitted.

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…

How can you lock in through charging money? Seems it’s like the opposite and they are charging because people are already locked in and they can or am I misreading your comment?

The idea is that they let you stay locked in for free. They dissuade people from making their CI pipeline forge-agnostic by charging you if you if you take steps to not be dependent on them. This means they can keep charging in other areas, and keep people in GitHub so that it stays dominant. Dominance is something that can be used to keep people in the Microsoft ecosystem, keep GitHub as the place where code goes so they have training data for LLMs, and dominance can simply be cashed in down the line.

I don’t know if that’s actually why they’re doing this, but it sounds plausible.

Re: Pricing Changes for GitHub Actions

#297

I’m genuinely excited about this. The GitHub actions platform is genuinely bad compared to circle or Travis but they’ve been totally crowded out because GitHub was just so easy to use. This has led to plenty of security issues and a general lack of innovation in the ci space. Hopefully by this pricing structure change we’ll see more investment in ci tooling across the industry

GitHub Actions were never too easy to use. But they were cheap to use, so anything more expensive had trouble competing.

Now the playing field is more level, yay. Fun for those who choose to migrate away.

Re: Pricing Changes for GitHub Actions

#298
post #274

The reason this makes sense, at least for Github, is because the only valid reason to run your own action runners is compliance. And if you are doing it for compliance, price doesn't really matter. You don't really have a choice. If you've been running your runners on your own infra for cost reasons, you're not really that interesting to the Github business.

I needed arm64 workers, because x86 would take ~25 minutes to do a build.

Re: Pricing Changes for GitHub Actions

#299
post #92

Earlier quoted context omitted.

it'd be great if they can couple this with an SLA for GitHub actions so we won't have to end up paying as much.. (ofc, that'd only mean they stop updating the status page, so eh)

For what it's worth, they already fail to update the status page. We had an "outage" just this morning where jobs were waiting 10+ minutes for an available runner -- resolved after half an hour or so but nothing was ever posted https://downdetector.com/status/github/

I don't want to shit on the Code to Cloud team but they act a lot like an internal infrastructure team when they're a product team with paying customers

Re: Pricing Changes for GitHub Actions

#300

Earlier quoted context omitted.

Codeberg's uptime is so bad, that it actually makes GitHub look good. ~96.5% over last 2 weeks [1] [1]: https://status.codeberg.org/status/codeberg

I'm sure if Codeberg had equivalent resources they'd be good, hard to fault a nonprofit for not benefiting from a trillion dollar multinational corporation. What was GitHub's excuse for their failures?

Are they a profit center yet?
Post reply on HN