Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ Schnitz 6 days ago

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

▲NamlchakKhandro 5 days ago | parent | next [-]

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

▲8-prime 5 days ago | parent | next [-]

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 5 days ago | parent | prev | next [-]

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

▲arw0n 5 days ago | parent [-]

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.

▲ornornor 5 days ago | parent | prev | next [-]

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

▲sunnyday_002 5 days ago | parent [-]

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 5 days ago | parent [-]

> 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 5 days ago | parent [-]

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.

▲falsedan 4 days ago | parent | next [-]

oh that makes sense. I thought the OP was suggesting running CI locally instead of a workflow on remote runners

▲sunnyday_002 4 days ago | parent | prev [-]

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
... ```
▲benrutter 5 days ago | parent | prev | next [-]

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 5 days ago | parent [-]

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 5 days ago | parent [-]

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 4 days ago | parent [-]

a display of great wisdom, nice

▲brian_cunnie 5 days ago | parent | prev | next [-]

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.

▲ 5 days ago | parent | prev [-]
[deleted]
▲mukundesh 5 days ago | parent | prev | next [-]

GitHub Actions are amazing ! For a public repository who will give you a free machine to run for 6 hours at a stretch for a job !!

▲__float 5 days ago | parent [-]

This thread is largely commentary on the technical aspects of GitHub Actions.

The fact the business gives away free compute is irrelevant and more a discussion of their marketing budget.

▲ablob 5 days ago | parent | prev | next [-]

Without trying to sound snarky: What is the fancy alternative you are suggesting to pull requests?

▲madog 5 days ago | parent [-]

Something like Gerrit. Instead of carefully crafting a logical series of patches that are all well documented with commit messages, PRs are just garbage filled diff soup of "fix typo" commits. I hate it. It's hard to review and seems to be based on putting the least amount of effort into proposing changes to the code. See https://gist.github.com/thoughtpolice/9c45287550a56b2047c631...

▲Cthulhu_ 5 days ago | parent | next [-]

That's down to culture and (self) discipline, not tools.

▲madog 5 days ago | parent [-]

It's not entirely, because Github simply does not support inter-version diffs when you have multiple commits. If you force push onto multiple commits there is no way to show a diff between version 2 and version 3 of those commits. How Github lacks such basic (and imo necessary) functionality in 2025 is amazing to me.

Something like linked and dependent PRs in a chain would go someway to replicating Gerrit but again this basic functionality is not available out of the box for whatever reason.

▲sublimefire 5 days ago | parent | prev [-]

Well but this is controllable, i.e. it is people who choose to do this not the platform. Very much an internal design choice.

▲ 5 days ago | parent [-]
[deleted]
▲bikelang 6 days ago | parent | prev [-]

Just curious - what do you think the current best git platforms are?

▲narrator 6 days ago | parent | next [-]

What ever happened to Hudson/Jenkins? That was the full featured CI/CD solution before github actions.

▲shawabawa3 5 days ago | parent | next [-]

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

▲paulddraper 5 days ago | parent | next [-]

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.

▲mrguyorama 5 days ago | parent [-]

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?

▲paulddraper 4 days ago | parent [-]

Assuming all those three were post-Jenkinsfile, it’s pretty decent.

Multibranch is still weird and obviously added-on.

Writing plugins is ugly.

▲terom 5 days ago | parent | prev [-]

Working with Jenkins CasC, JobDSL and declarative pipelines, I'm not sure where the million times comes from. Sure, there are some annoying parts, and GHA has the social network for reusable actions, but apart from that it's not that different.

Oldschool maven type jobs where you type shell script into a `<textarea>`? Yeah, let's not talk about those, but we don't have a single one left anymore.

▲__float 5 days ago | parent [-]

Jenkins Groovy is awful and full of footguns. Have you ever run into a serialization exception?

It's too powerful and there are too many of its implementation details exposed to the user.

▲terom 5 days ago | parent [-]

I haven't seen a serialization exception, but I have run into plenty of footguns with YAML (ref GitHub Actions).

The DSL semantics can be weird with when things like params/env expansions in options block are evaluated.

▲robot-wrangler 5 days ago | parent | prev [-]

That also is/was awful. But it's just another platform like GHA, and the solution to this kind of thing is always the same, should not be surprising, and is boring in the good way. Write automation so that it's not tightly coupled to the platform on the backend. If you can't migrate between platforms then you're eventually going to be unhappy.

If someone is forcing you towards high stakes tight-coupling with no thought whatsoever towards the lock-in, you should get it in writing that "we at ${org} are fully committed to ${vendor} with ${platform}, on ${cloud} using ${tech} come what may, now and forever" and lots of sign off so that everyone knows who to blame when this is inevitably wrong.

▲aetherspawn 6 days ago | parent | prev | next [-]

Azure DevOps is the gold standard for Pipelines.

▲noahbp 6 days ago | parent | next [-]

That's not saying much, since it's still dependent upon the untyped mess that is YAML.

▲0xbadcafebee 6 days ago | parent | next [-]

YAML is just a data format. Make your own "thing" that takes input in any format you desire, then dump it to YAML. (also, YAML is dynamically typed, and supports explicit typing, but the parser can choose to ignore it)

▲lucyjojo 4 days ago | parent | prev [-]

these days we generate yaml out of cue

i don't know why it's not more popular.

▲ic_fly2 5 days ago | parent | prev | next [-]

Really?

I grant you pipelines are the best bit about ado, but the fact that you can’t test them is a pain.

And the webhooks and templating are pretty messy and unpleasant quickly.

We’re changing from ADO to GitHub (had to be an MS product for corporate) and the infra people are looking forward to GHA as they prefer their maintenance to ADO pipelines.

▲ghqqwwee 6 days ago | parent | prev | next [-]

AD is just sourcesafe/tfs/vsts with rebranding, each time trying to get rid of the bad reputation in developer circles.

▲vrighter 6 days ago | parent | prev | next [-]

if only they supported ed25519 ssh keys

▲ 6 days ago | parent | prev [-]
[deleted]
▲SpaceNoodled 6 days ago | parent | prev [-]

git