5 ms·

I got contacted by our rep a couple weeks ago, who informed me of this news. I thought it was a disaster and it really pissed me off. The rep couldn't even expl

by golovast 10mo ago

I got contacted by our rep a couple weeks ago, who informed me of this news. I thought it was a disaster and it really pissed me off. The rep couldn't even explain the reasoning well. It basically summed up to "because we can" and "where are you going to go?". He was shocked to find out that I didn't like it. We currently self-host on kubernets/aws. The thing that really got to me isn't the new charge per se. It's the fact that GHA has a ton of problems. I can hold my nose and deal with them when it's free. But now that you're squeezing me, at least you could have created something like GHA 2.0 and added a charge for that. Instead, there are vague roadmap promises which don't even include things that I care about. Specifically: - Jenkins had better kubernetes integration years ago. It's crazy that GHA can't beat that. - "Reintroducing multi-label functionality" - yeah, so they first broke it. They did supply "reasons", which looked like they never talked to a customer. [1] - Still no SDK of any kind. - "Actions Data Stream" - or you can just fix your logging. There are dozens more complains, which are easy enough to find. This kind of an approach just makes me want to make sure that I don't use GHA again. Even if I end up paying another vendor, at least I'll be treated as a customer. [1] - https://github.com/orgs/community/discussions/160682#discussioncomment-8063837 https://github.com/orgs/community/discussions/160682#discuss...

esafak 10mo ago
Any official Github action today: "Thank you for your interest in this GitHub action, however, right now we are not taking contributions. We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in."
- replete 9mo ago
  They are focusing on an Azure migration for then next 2 years...
- paulddraper 10mo ago
  Reference: https://github.com/actions/runner?tab=readme-ov-file#note https://github.com/actions/runner?tab=readme-ov-file#note
tetha 10mo ago
This kinda change also has some different gears turning in my head. At $0.002 / build-minute, some of our large software integration tests would cost us around 15 - 20 cents. Some of our ansible integration tests would be 5 - 10 cents - and we run like 50 - 100 of those per day. Some deployments might cost us a cent or two. Apples to oranges, naturally, but like this, our infra-jenkins master would pay for itself in hosting in a week of ansible integration testing compared to what GHA would cost. Sure, maintenance is a thing, but honestly, flinging java, docker and a few other things onto a build agent isn't the time-consuming part of maintaining CI infrastructure. And I mean sure, everything is kinda janky on Jenkins, but everything falls into an expectable corridor of jank you get used to.
- tonfreed 10mo ago
  Last place I worked had long running end to end tests that would take 30 minutes on GHA (compared to maybe 5 locally) on every PR. This is going to make that a very expensive endeavour
  - rcoder 10mo ago
    We host a fair bit of Terraform code in a repos on GitHub, including the project that bootstraps and manages our GH org’s config: permissions, repos, etc. Hilariously, the official Terraform provider for GitHub is full of N+1 API call patterns — aka exponential scaling hotspots — so even generating a plan requires making a separate (remote, rate-limited) API call to check things like the branch protection status of every “main” branch, every action and PR policy, etc. As of today it takes roughly 30 minutes to do a full plan, which has to run as part of CI to make sure the pushed TF code is valid. With this change, we’ll be paying once to host our projects and again for the privilege of running our own code on our own machines when we push changes…and the bill will continue to grow exponentially b/c the speed of their API serves to set an artificial lower bound on the runtime of our basic tests. (To be fair, “slow” and “Terraform” often show up and leave parties at suspiciously similar times, and GitHub is far from the only SaaS vendor whose revenue goes up when their systems get slower.)
- Marsymars 10mo ago
paulddraper 10mo ago
GitHub Actions runners are hard to self-host. The runner configuration and registration process is unnecessarily byzantine. [1] They can't cancel jobs cleanly. [2] There are consistency problems everywhere. [3] Their own documentations describes horrible things unless you use runners in JIT mode. Though JIT runners are not always removed after exit. If there is a worse self-hosted CI runner, I haven't yet met it. [1] https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners https://docs.github.com/en/actions/how-tos/manage-runners/se... [2] https://github.com/orgs/community/discussions/26311 https://github.com/orgs/community/discussions/26311 [3] https://github.com/orgs/community/discussions/62365 https://github.com/orgs/community/discussions/62365
- pxc 10mo ago
  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.
  - paulddraper 10mo ago
    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.
    - gheltllck 10mo ago
      Hard-linking and running concurrent self-updates, sounds like a recipe for disaster.
    - pxc 10mo ago
      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?
madeofpalk 10mo ago
It seems clear to me this is in response to all the third party GHA runners who were undercutting GitHub by just reselling cloud instances for cheaper. They’ve lowered their runner costs to compete, and introduce minimum charge to discourage abd make sure they still get paid.
- az226 10mo ago
  100% this. They could have made their service better or more competitive like with price but instead they chose this route. SMH.
bigbuppo 10mo ago
Nearly 20 years ago, some VP at a security products company now owned by Broadcom threatened us during contract renewal with, "The price is what it is. Your contract is up in two weeks. What are you going to do? Move to a competing product?" We had it done with a week to spare.
- xinsight 10mo ago
  Never underestimate the power of spite! :)
deleted 10mo ago
[deleted]

esafak 10mo ago

Any official Github action today: "Thank you for your interest in this GitHub action, however, right now we are not taking contributions. We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in."

replete 9mo ago
They are focusing on an Azure migration for then next 2 years...
paulddraper 10mo ago
Reference: https://github.com/actions/runner?tab=readme-ov-file#note https://github.com/actions/runner?tab=readme-ov-file#note

tetha 10mo ago

This kinda change also has some different gears turning in my head. At $0.002 / build-minute, some of our large software integration tests would cost us around 15 - 20 cents. Some of our ansible integration tests would be 5 - 10 cents - and we run like 50 - 100 of those per day. Some deployments might cost us a cent or two. Apples to oranges, naturally, but like this, our infra-jenkins master would pay for itself in hosting in a week of ansible integration testing compared to what GHA would cost. Sure, maintenance is a thing, but honestly, flinging java, docker and a few other things onto a build agent isn't the time-consuming part of maintaining CI infrastructure. And I mean sure, everything is kinda janky on Jenkins, but everything falls into an expectable corridor of jank you get used to.

tonfreed 10mo ago
Last place I worked had long running end to end tests that would take 30 minutes on GHA (compared to maybe 5 locally) on every PR. This is going to make that a very expensive endeavour
- rcoder 10mo ago
  We host a fair bit of Terraform code in a repos on GitHub, including the project that bootstraps and manages our GH org’s config: permissions, repos, etc. Hilariously, the official Terraform provider for GitHub is full of N+1 API call patterns — aka exponential scaling hotspots — so even generating a plan requires making a separate (remote, rate-limited) API call to check things like the branch protection status of every “main” branch, every action and PR policy, etc. As of today it takes roughly 30 minutes to do a full plan, which has to run as part of CI to make sure the pushed TF code is valid. With this change, we’ll be paying once to host our projects and again for the privilege of running our own code on our own machines when we push changes…and the bill will continue to grow exponentially b/c the speed of their API serves to set an artificial lower bound on the runtime of our basic tests. (To be fair, “slow” and “Terraform” often show up and leave parties at suspiciously similar times, and GitHub is far from the only SaaS vendor whose revenue goes up when their systems get slower.)
Marsymars 10mo ago

paulddraper 10mo ago

GitHub Actions runners are hard to self-host. The runner configuration and registration process is unnecessarily byzantine. [1] They can't cancel jobs cleanly. [2] There are consistency problems everywhere. [3] Their own documentations describes horrible things unless you use runners in JIT mode. Though JIT runners are not always removed after exit. If there is a worse self-hosted CI runner, I haven't yet met it. [1] https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners https://docs.github.com/en/actions/how-tos/manage-runners/se... [2] https://github.com/orgs/community/discussions/26311 https://github.com/orgs/community/discussions/26311 [3] https://github.com/orgs/community/discussions/62365 https://github.com/orgs/community/discussions/62365

pxc 10mo ago
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.
- paulddraper 10mo ago
  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.
  - gheltllck 10mo ago
    Hard-linking and running concurrent self-updates, sounds like a recipe for disaster.
  - pxc 10mo ago
    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?

madeofpalk 10mo ago

It seems clear to me this is in response to all the third party GHA runners who were undercutting GitHub by just reselling cloud instances for cheaper. They’ve lowered their runner costs to compete, and introduce minimum charge to discourage abd make sure they still get paid.

az226 10mo ago
100% this. They could have made their service better or more competitive like with price but instead they chose this route. SMH.

bigbuppo 10mo ago

Nearly 20 years ago, some VP at a security products company now owned by Broadcom threatened us during contract renewal with, "The price is what it is. Your contract is up in two weeks. What are you going to do? Move to a competing product?" We had it done with a week to spare.

xinsight 10mo ago
Never underestimate the power of spite! :)

deleted 10mo ago

[deleted]