The Pain That Is GitHub Actions • Hacker News Board

Re: The Pain That Is GitHub Actions

#391

Post by rbongers » Thu, Mar 20, 2025, 8:04 PM UTC

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

In my opinion, unless if you need its ability to figure out when something should rebuild or potentially if you already use it, Make is not the right tool for the job. You should capture your pipeline jobs in scripts or similar, but Make just adds another language for developers to learn on top of everything. Make is not a simple script runner.

I maintained a Javascript project that used Make and it just turned into a mess. We simply changed all of our `make some-job` jobs into `./scripts/some-job.sh` and not only was the code much nicer, less experienced developers were suddenly more comfortable making changes to scripts. We didn't really need Make to figure out when to rebuild anything, all of our tools already had caching.

Re: The Pain That Is GitHub Actions

#392

Post by steeleduncan » Thu, Mar 20, 2025, 8:04 PM UTC

mikepurvis wrote: post #389

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

Strongly isolated systems like Nix and Bazel are amazing for giving no-fuss local reproducibility. Every CI "platform" is trying to seduce you into breaking things out into steps so that you can see their little visualizations of what's running in parallel or write special logic in groovy or JS to talk to an API and generate notifications or badges or whatever on the build page. All of that is cute, but it's ultimate…

> Write as much CI logic as possible in your own code

Nix really helps with this. Its not just that you do everything via a single script invocation, local or ci, you do it in an identical environment, local or ci. You are not trying to debug the difference between Ubuntu as setup in GHA or Arch as it is on your laptop.

Setting up a nix build cache also means that any artefact built by your CI is instantly available locally which can speed up some workflows a lot.

Re: The Pain That Is GitHub Actions

#393

Post by ashishb » Thu, Mar 20, 2025, 8:06 PM UTC

rsanheim wrote: post #325

ashishb wrote: post #48

Earlier quoted context omitted.

> There are better solutions out there. And what are those?

CircleCI.

I used to use circle CI earlier. GitHub Actions was an upgrade for me.

Re: The Pain That Is GitHub Actions

#394

Post by ashishb » Thu, Mar 20, 2025, 8:07 PM UTC

throwaway984393 wrote: post #56

ashishb wrote: post #48

Earlier quoted context omitted.

> There are better solutions out there. And what are those?

Drone.io

Will it last another 2 years? Several CI systems have come and gone.

Re: The Pain That Is GitHub Actions

#395

Post by danfritz » Thu, Mar 20, 2025, 8:13 PM UTC

Not my experience, I have done fairly complex things like building / releasing a whitelabel ios and android app which is branded in ci per customer.

Like othes have suggested, keep the actions simple by having lots of scripts which you can iterate on locally and making the actions dump to just run the scripts

Re: The Pain That Is GitHub Actions

#396

Post by psyclobe » Thu, Mar 20, 2025, 8:14 PM UTC

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

'* Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code.'

THIS 10000% percent.

Re: The Pain That Is GitHub Actions

#397

Post by specialist » Thu, Mar 20, 2025, 8:17 PM UTC

mikepurvis wrote: post #389

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

Strongly isolated systems like Nix and Bazel are amazing for giving no-fuss local reproducibility. Every CI "platform" is trying to seduce you into breaking things out into steps so that you can see their little visualizations of what's running in parallel or write special logic in groovy or JS to talk to an API and generate notifications or badges or whatever on the build page. All of that is cute, but it's ultimate…

We used to just tail the build script's output.

Maybe add some semi-structured log/trace statements for the CI to scrap.

No hooks necessary.

Re: The Pain That Is GitHub Actions

#398

Post by mikepurvis » Thu, Mar 20, 2025, 8:18 PM UTC

steeleduncan wrote: post #392

mikepurvis wrote: post #389

Earlier quoted context omitted.

Strongly isolated systems like Nix and Bazel are amazing for giving no-fuss local reproducibility. Every CI "platform" is trying to seduce you into breaking things out into steps so that you can see their little visualizations of what's running in parallel or write special logic in groovy or JS to talk to an API and generate notifications or badges or whatever on the build page. All of that is cute, but it's ultimate…

> Write as much CI logic as possible in your own code Nix really helps with this. Its not just that you do everything via a single script invocation, local or ci, you do it in an identical environment, local or ci. You are not trying to debug the difference between Ubuntu as setup in GHA or Arch as it is on your laptop. Setting up a nix build cache also means that any artefact built by your CI is instantly available…

Absolutely. Being able to have a single `nix build` line that gets all the way from source to your final asset (iso, ova, container image, whatever) with everything being aggressively cached all the way along is a game changer. I think it's worth the activation energy for a lot more organizations than realize it.

Re: The Pain That Is GitHub Actions

#399

Post by Lammy » Thu, Mar 20, 2025, 8:21 PM UTC

deng wrote: post #153

qweiopqweiop wrote: post #128

Earlier quoted context omitted.

Can you explain YAML? I've found declarative pipelines with it have been... fine?

YAML is fine for what it is: a markup language. I have no problem with it being used in simple configuration files, for instance. However, CI is not "configured", it is coded. It is simply the wrong tool. YAML was continuously extended to deal with that, so it developed into much more than just "markup", but it grew into this terrible chimera. Once you start using advanced features in GitLab's YAML like anchors and r…

> YAML is fine for what it is: a markup language.

Pardon my pedantry, but the meaning of YAML's name was changed from the original “Yet Another Markup Language” to “YAML Ain't Markup Language” in a 2002 draft spec because YAML is, in fact, not a markup language :)

Compare:

https://yaml.org/spec/history/2001-12-10.html

https://yaml.org/spec/history/2002-04-07.html

Re: The Pain That Is GitHub Actions

#400

Post by mikepurvis » Thu, Mar 20, 2025, 8:21 PM UTC

specialist wrote: post #397

mikepurvis wrote: post #389

Earlier quoted context omitted.

Strongly isolated systems like Nix and Bazel are amazing for giving no-fuss local reproducibility. Every CI "platform" is trying to seduce you into breaking things out into steps so that you can see their little visualizations of what's running in parallel or write special logic in groovy or JS to talk to an API and generate notifications or badges or whatever on the build page. All of that is cute, but it's ultimate…

We used to just tail the build script's output. Maybe add some semi-structured log/trace statements for the CI to scrap. No hooks necessary.

That works so long as the build script is just doing a linear series of things. But if it's anything remotely modern then a bunch of stuff is going on in parallel, and if all the output is being funneled to a single log, you can end up with a fair bit of wind-down spew you have to scroll through to find the real/initial failure.

How much better would it be if the CI web client could just say, here's everything the build tool built, with their individual logs, and here's a direct link to the one that failed, which canceled everything else?