3 ms·

100% don't understand why people think github actions are terrible. everything else is trash. Github Actions changed the landscape. They're composable. The

100% don't understand why people think github actions are terrible. everything else is trash. Github Actions changed the landscape. They're composable. The only two other things that come close is Concourse.CI and CircleCi.... and circle-ci is 100% trash

ornornor 10mo ago
Versioning sucks (the references are mutable), debugging sucks, you cant run them locally.
- sunnyday_002 10mo ago
  Pin the action's version via a digest and use Renovate for updates. You can run all your CI locally if you don't embed your logic into the workflows, just use CI for orchestation. Use an env manager(Mise, Nix etc) to install tooling(you'll get consistency across your team & with CI) and call out to a task runner(scripts, Make, Task etc).
  - falsedan 10mo ago
    > You can run all your CI locally if you can, you don't need CI. we can't (too slow, needs an audit trail)
    - itintheory 10mo ago
      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.
      - sunnyday_002 10mo ago
        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 ... ```
      - falsedan 10mo ago
        oh that makes sense. I thought the OP was suggesting running CI locally instead of a workflow on remote runners
8-prime 10mo ago
Github Actions is a cobbled together mess. It is mainly based on Azure DevOps Pipelines and still has some glaring bugs and wildly inefficient parts. If it works for you, great. But it is far from being good.
xenator 10mo ago
We use Gitlab for CI/CD and tbh it is amazing. Simple, predictable, debuggable.
- arw0n 10mo ago
  This whole thread is various people saying "[This] is trash, [that] is awesome", with the next person claiming the opposite. I suspect most people with strong negative opinions here know enough to have felt the pain, and not enough to be able to properly reason about the system. I've worked with Github Actions, Gitlab-CI and CircleCI in the last 10 years, and they've all been such an improvement over Jenkins, or god forbid, CVS with manual deployments, that I'm generally just counting my blessings. For me the pain only came when not adhering to KISS. All the mentioned VCS are pretty much feature complete and only really differ on meta-topics (cost, license, lock-in) or niche topics (Actions marketplace, matrix builds, SSH on Runners). I've not yet run into an issue that would have actually blocked me, because there's always sh to fall back to in case of a bug or missing feature.
deleted 10mo ago
[deleted]
benrutter 10mo ago
I think I agree with you that: - everything else is trash. - Github Actions changed the landscape. - They're composable. And I still hate github actions! Aside from anything else, they have one major flaw, which is there is no good development/test loop for writing them. If you write most of your CICD in some kind of script, then you can run it locally, and do some basic checks around environment etc before deploying. If you write most of your CICD in github actions or any alternative, you will be doomed to push 100 commits with messages like "maybe be?", "hmmm. . ." before eventually squashing them all down when it turns out several hours later that you mispelt an environment variable.
- falsedan 10mo ago
  top tip: make a repo in your org for pushing all these nonsense changes to, test out your workflows with a dummy package being published to the repo, work out all the weird edge cases/underdocumented features of Actions once you're done, make the actual changes in your real repo. I call the test repo 'pincushion'
  - hadlock 10mo ago
    We call ours "bombing-range" We maintain an internal service that hosts two endpoints; /random-cat-picture (random >512KB image + UUID + text timestamp to evade caching) and /api/v1/generic.json which allows developers and platform folks to test out new ideas from commit to deploy behind a load balancer in an end-to-end fashion, it has saved countless headaches over the years.
    - falsedan 10mo ago
      a display of great wisdom, nice
brian_cunnie 10mo ago
Thumbs up on Concourse CI: I like seeing all my builds at once on any easy-to-read dashboard. That’s why we switched from GitHub actions: the dashboard.

ornornor 10mo ago

Versioning sucks (the references are mutable), debugging sucks, you cant run them locally.

sunnyday_002 10mo ago
Pin the action's version via a digest and use Renovate for updates. You can run all your CI locally if you don't embed your logic into the workflows, just use CI for orchestation. Use an env manager(Mise, Nix etc) to install tooling(you'll get consistency across your team & with CI) and call out to a task runner(scripts, Make, Task etc).
- falsedan 10mo ago
  > You can run all your CI locally if you can, you don't need CI. we can't (too slow, needs an audit trail)
  - itintheory 10mo ago
    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.
    - sunnyday_002 10mo ago
      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 ... ```
    - falsedan 10mo ago
      oh that makes sense. I thought the OP was suggesting running CI locally instead of a workflow on remote runners

8-prime 10mo ago

Github Actions is a cobbled together mess. It is mainly based on Azure DevOps Pipelines and still has some glaring bugs and wildly inefficient parts. If it works for you, great. But it is far from being good.

xenator 10mo ago

We use Gitlab for CI/CD and tbh it is amazing. Simple, predictable, debuggable.

arw0n 10mo ago
This whole thread is various people saying "[This] is trash, [that] is awesome", with the next person claiming the opposite. I suspect most people with strong negative opinions here know enough to have felt the pain, and not enough to be able to properly reason about the system. I've worked with Github Actions, Gitlab-CI and CircleCI in the last 10 years, and they've all been such an improvement over Jenkins, or god forbid, CVS with manual deployments, that I'm generally just counting my blessings. For me the pain only came when not adhering to KISS. All the mentioned VCS are pretty much feature complete and only really differ on meta-topics (cost, license, lock-in) or niche topics (Actions marketplace, matrix builds, SSH on Runners). I've not yet run into an issue that would have actually blocked me, because there's always sh to fall back to in case of a bug or missing feature.

deleted 10mo ago

[deleted]

benrutter 10mo ago

I think I agree with you that: - everything else is trash. - Github Actions changed the landscape. - They're composable. And I still hate github actions! Aside from anything else, they have one major flaw, which is there is no good development/test loop for writing them. If you write most of your CICD in some kind of script, then you can run it locally, and do some basic checks around environment etc before deploying. If you write most of your CICD in github actions or any alternative, you will be doomed to push 100 commits with messages like "maybe be?", "hmmm. . ." before eventually squashing them all down when it turns out several hours later that you mispelt an environment variable.

falsedan 10mo ago
top tip: make a repo in your org for pushing all these nonsense changes to, test out your workflows with a dummy package being published to the repo, work out all the weird edge cases/underdocumented features of Actions once you're done, make the actual changes in your real repo. I call the test repo 'pincushion'
- hadlock 10mo ago
  We call ours "bombing-range" We maintain an internal service that hosts two endpoints; /random-cat-picture (random >512KB image + UUID + text timestamp to evade caching) and /api/v1/generic.json which allows developers and platform folks to test out new ideas from commit to deploy behind a load balancer in an end-to-end fashion, it has saved countless headaches over the years.
  - falsedan 10mo ago
    a display of great wisdom, nice

brian_cunnie 10mo ago

Thumbs up on Concourse CI: I like seeing all my builds at once on any easy-to-read dashboard. That’s why we switched from GitHub actions: the dashboard.