Live data from Hacker News

Pricing Changes for GitHub Actions

resources.github.com

831–840 of 853 posts

Re: Pricing Changes for GitHub Actions

#831

Earlier quoted context omitted.

I'm not at all a fan of GitHub actions, but come on, Hudson/Jenkins was a nightmare world, GitHub actions is a million times better

Jenkins is in every way a “Java” program, and not the good kind. What you can say for it, is that it was free and near infinitely hackable.

I use Jenkins every single day, and have been using it my entire career through three different companies self hosting it.

Please tell me how we somehow have been hobbled despite having simple and clear pipelines setup that autobuild any branch we want and allow one click deploys to our preprod environment and automatically manage versioning and scalably handle load from "Literally zero" to "Everyone in the company wants to rebuild everything now" and goes down less than github.

What are we supposedly missing?

More importantly, what are we missing that tangibly improves results for our consumers?

Re: Pricing Changes for GitHub Actions

#832
post #714

Earlier quoted context omitted.

Whatever your issues with the price, this comment is truly wild. When you’re using commercial PyCharm, you’re paying JetBrains to “run their software on your hardware.”

A one-off software license (or even a subscription) is completely different. The issue is metered billing for something you are paying for already which costs the company nothing. The equivalent is not only paying a flat monthly fee to Adobe for access to Photoshop, but also an additional charge for how long you have it open on your machine every month.

I’d like to introduce you to Oracle and many software companies pre-SaaS that were charging per core.

If I recall correctly, Atlassian’s CI product also charged you for parallel jobs back in the day. And businesses were paying it because they felt it gave them value for money.

Re: Pricing Changes for GitHub Actions

#833
post #781

Earlier quoted context omitted.

> Companies can get into legal trouble if they don't. Heard of Meta torrenting copyrighted material? What kind of trouble did they get into?

What if they lost? Open source license litigation is a thing: https://en.wikipedia.org/wiki/Open_source_license_litigation

Not sure what you are trying to say. What I see is that in practice, TooBigTech can do their training with everything they want without any meaningful consequence.

Re: Pricing Changes for GitHub Actions

#834
post #428

Earlier quoted context omitted.

It is containers. It's based on Nixery, which is a virtual Docker registry where it puts together containers for you on the fly containing whatever packages you want from Nixpkgs.

By containers I mean I get to define my CI environment with containers, not nix or that somewhere under the hood containers are being used Like Argo or Jenkins. Pushing nix as the DX for GHA equivalent was a poor choice by Tangled IMO. It's too unusual for your average dev, I'm not interested in learning nix so I can use CI.

Your username is vaguely familiar. You're a CUE enthusiast, right? I think I've read (and enjoyed and benefited from) some documentation you've written!

Yeah, I think it makes sense to also let people point to arbitrary OCI registries. I'd bet support for that is coming, especially since the execution environment is Dockerized anyway.

> Pushing nix as the DX for GHA equivalent

I think something like Nix actually makes more sense than YAML for this kind of thing. You want a DSL that is purpose-built so that configurations are declarative, simple configurations are simple to write, and configurations are composable. YAML is too much of a straightjacket. Some kind of built-in support for deep merges is a must, imo.

How powerful/expressive the language should be is debatable, I think. I'm interested in Turing-complete DSLs like Nix and Nickel, but CUE could be a good fit here, too.

Anyway I'm sure they'll add first-class support for using some OCI artifact to define a CI environment. Looks like their CI implementation only recently entered the first alpha.

Re: Pricing Changes for GitHub Actions

#835

Earlier quoted context omitted.

At work we've started switching to codeberg (which uses forgejo) and honestly it's a breath of fresh air compared to GitHub. It's blazing fast compared to GitHub and has feature parity with our needs.

I have (almost completely) moved my business from GitHub to Forgejo as well. I’m deploying an instance at home as well. It’s shocking how bloated and slow GitHub is even for basic actions when you compare it to Forgejo running just your own stuff. Bonus: if you can manage to reliably backup a database and a filesystem, you can then backup your forge. Outside GH Enterprise there is still no restorable backup option in…

This is great to hear! I’ll check it out.

How is it for usability (other than speed) compared to GH. Given that most/all devs are already comfortable in GH. What are the downsides in your experience?

Re: Pricing Changes for GitHub Actions

#836
post #635
post #582

Earlier quoted context omitted.

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

“not my money” thinking will always indirectly lead to bad things for you on a long enough timeline. Edit: this got flagged, but if you end up in an unprofitable position because you chose Oracle as a vendor and they squeezed your company so hard they need to choose between paying you (either via a raise or via actually employing you) or staying with a vendor thats squeezing them; they will choose the latter, as its…

I think you can take it too far and spend a lot of time worrying about nickel and dimes for someone who doesn't care... github is unlikely to eat a business and if it does you made some bad choices.

Otherwise you make the call, maybe the company changes their business practices for the worse, maybe they don't ... it's not like you can ever be sure about that.

Re: Pricing Changes for GitHub Actions

#837
post #54

That's not a move of a company that thinks it can still grow. That's a Netflix "we have 90% of the market, let's squeeze them" move. This is the beginning. We have all seen this pattern over the last 5+ years. You know their next few moves.

The Netflix one worked

> The Netflix one worked

Did it, though? User frustration seems to be growing, people are already seeking out alternatives

Re: Pricing Changes for GitHub Actions

#838

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…

> learn from our mistakes and convince our teams and management to use community-maintained, libre alternatives Every company I've been at that tried to self-host something like GitLab, later moved to GitHub. Nobody in business cares if it's open source/free software. They care about managed hosting, centralized services, invoicing, etc. DIY is great for hobbyists and the cash-strapped.

Yours is a fairly cynical take, if realistic. It's true that hosting a forge or code repo is fairly complex and doesn't move the needle for most businesses, but…

As a CTO at a small company, I chose to self-host key infrastructure or picked small players to avoid tech giants. Perhaps there'll be more businesses like that, where decision makers put their money where their mouth is.

Re: Pricing Changes for GitHub Actions

#839
post #23

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.

We've self-hosted github actions in the past, and self-hosting it doesn't help all that much with the fragile part. For github it is just as much triggering the actions as it is running them. ;) I hope the product gets some investment, because it has been unstable for such a long time, that on the inside it must be just the usual right now. GitHub has by far the worst uptime of any SaaS tools we use at the moment, an…

In 2023 I quoted a customer some 30 hours to deploy a Kubernetes cluster to Hetzner specifically to run self-hosted GitHub Actions Runners.

After 10-ish hours the cluster was operational. The remaining 18 (plus 30-something unbillable to satisfy my conscience) were spent trying and failing to diagnose an issue which is still unsolved to this day[1].

[1]: https://github.com/actions/runner-container-hooks/issues/113

Re: Pricing Changes for GitHub Actions

#840

Earlier quoted context omitted.

> You can run all your CI locally if you can, you don't need CI. we can't (too slow, needs an audit trail)

I think the idea is GitHub actions calls "build.sh", or "deploy.sh" etc. Those scripts contain all of the logic necessary to build or deploy or whatever. You can run those scripts locally for testing / development, or from CI for prod / auditing.

Yes this is what I meant! If you structure it correctly using task runners and an environment manager you can do everything locally using the same versions etc. E.g.

```yaml name: Continuous Integration (CI)

on: pull_request

permissions: contents: read

jobs: formatting: name: Formatting runs-on: ${{ matrix.architecture }} strategy: matrix: architecture: [ubuntu-24.04, ubuntu-24.04-arm] language: [rust, shell, python] steps: - name: Checkout code. uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 - name: Setup Nix. uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0 - name: Check formatting. run: nix develop -c make check-${{ matrix.language }}-formatting

  linting:
    name: Linting
    runs-on: ${{ matrix.architecture }}
    strategy:
      matrix:
        architecture: [ubuntu-24.04, ubuntu-24.04-arm]
        language: [rust]
    steps:
      - name: Checkout code.
        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
      - name: Setup Nix.
        uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0
      - name: Check linting.
        run: nix develop -c make check-${{ matrix.language }}-linting

  compile:
    name: Compile
    runs-on: ${{ matrix.architecture }}
    strategy:
      matrix:
        architecture: [ubuntu-24.04, ubuntu-24.04-arm]
    steps:
      - name: Checkout code.
        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
      - name: Setup Nix.
        uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0
      - name: Compile.
        run: nix develop -c make compile

  unit-test:
    name: Unit Test
    runs-on: ${{ matrix.architecture }}
    strategy:
      matrix:
        architecture: [ubuntu-24.04, ubuntu-24.04-arm]
    steps:
      - name: Checkout code.
        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
      - name: Setup Nix.
        uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0
      - name: Unit test.
        run: nix develop -c make unit-test
... ```
Post reply on HN