Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

81–90 of 347 posts

Re: I hate GitHub Actions with passion

#81
post #2

Would a tool like act help here? ( https://github.com/nektos/act ) I suppose orchestration that is hiding things from different processor architectures could also very well run differently online than offline, but still.

I haven’t looked into act for some time but I remember it NOT being a direct stand in locally. Like it covered 80% of use cases. Maybe that has changed.

That's correct and it's linux-only (as of the last time I looked), you can run it on macOS but you can't run macOS runners (which is where I need the most help debugging normally, for building iOS apps).

Re: I hate GitHub Actions with passion

#82

1. Don't use bash, use a scripting language that is more CI friendly. I strongly prefer pwsh. 2. Don't have logic in your workflows. Workflows should be dumb and simple (KISS) and they should call your scripts. 3. Having standalone scripts will allow you to develop/modify and test locally without having to get caught in a loop of hell. 4. Design your entire CI pipeline for easier debugging, put that print state in, e…

I don't agree with (1), but agree with (2). I recommend just putting a Makefile in the repo and have that have CI targets, which you can then easily call from CI via a simple `make ci-test` or similar. And don't make the Makefiles overcomplicated. Of course, if you use something else as a task runner, that works as well.

Makefile or scripts/do_thing either way this is correct. CI workflows should only do 1 thing each step. That one thing should be a command. What that command does is up to you in the Makefile or scripts. This keeps workflows/actions readable and mostly reusable.

Re: I hate GitHub Actions with passion

#83
post #26

Earlier quoted context omitted.

I mean, at some point you are bash calling some other language anyway . I'm a huge fan of "train as you fight", whatever build tools you have locally should be what's used in CI. If your CI can do things that you can't do locally: that is a problem.

> If your CI can do things that you can't do locally: that is a problem. Probably most of the times when this is an actual problem, is building across many platforms. I'm running Linux x86_64 locally, but some of my deliverables are for macOS and Windows and ARM, and while I could cross-compile for all of them on Linux (macOS was a bitch to get working though), it always felt better to compile on the hardware I'm tar…

I literally had to do this push > commit > test loop yesterday because apparently building universal Python wheels on MacOS is a pain in the ass. And I don't have a mac, so if I want to somewhat reliably reproduce how the runner might behave, I have to either test it on GH actions or rent one from something like Scaleway. Mainly because I don't currently knwo how else to do it. It's so, so frustrating and if anyone has ideas on making my life a bit better that would be nice lol.

Re: I hate GitHub Actions with passion

#84
post #46

Earlier quoted context omitted.

This is basically how most other CI systems work. GitLab CI, Jenkins, Buildbot, Cirrus CI, etc. are all other systems I've used and they work this way. I find GitHub Actions abhorrent in a way that I never found a CI/CD system before...

as usual for Microslop products: it's designed for maximum lock-in everything is including some crappy proprietary yaml rather than using standard tooling so instead of being a collection of easily composable and testable bits it's a mess that only works on their platform

It seems more of a cultural issue that -- I'm pretty sure -- predates Microsoft's acquisition of GitHub. I assume crappy proprietary yaml can be blamed on use of Ruby. And there seems to be an odd and pervasive "80% is good enough" feel to pretty much everything in GitHub, which is definitely cultural, and I'm pretty sure, also predates Microsoft's acquisition.

Re: I hate GitHub Actions with passion

#85

Earlier quoted context omitted.

> Huh? Who cares if the script is .sh, .bash, Makefile, Justfile, .py, .js or even .php? Me, typically I have found it to be a sign of over-engineering and found no benefits over just using shell script/task runner, as all it should be is plumbing that should be simple enough that a task runner can handle it. > If it works it works, as long as you can run it locally, it'll be good enough, Maybe when it is your own pe…

> But personally so far everytime I have come across something not using a task runner it has just been the wrong decision. Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end. Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they impl…

> Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end.

Strong opinions, loosely held :)

> Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they implement things, rather than "over-engineering"

Funnily enough running with the first idea I think is creating a lot of the "over-engineering" I am seeing. Not stopping to consider other simpler solutions or even if the problem needs/is worth solving in the first place.

> Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end.

I quickly asked Claude to convert one of my open source repos using Make/Nix/Shell -> Python/Nix to see how it would look. It is actually one of the better Python as a task runners I have seen.

* https://github.com/DeveloperC286/clean_git_history/pull/431

While the Python version is not as bad as I have seen previously, I am still struggling to see why you'd want it over Make/Shell.

It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI).

It is less maintainable as it is more code, roughly x3 the amount of the Makefile.

To me the Python code is more verbose and not as simple compared to the Makefile's target so it is less readable as well.

Re: I hate GitHub Actions with passion

#87

The love for Github Actions dissipated fast, it wasn't that long ago we had to read about how amazing Github Actions where. What changed?

I think it's possible to both think GitHub Actions is an incredible piece of technology (and an incredible de facto public resource), while also thinking it has significant architectural and experiential flaws. The latter can be fixed; the former is difficult for competitors to replicate.

(In general, I think a lot of criticisms of GitHub Actions don't consider the fully loaded cost of an alternative -- there are lots of great alternative CI/CD services out there, but very few of them will give you the OS/architecture matrix and resource caps that GitHub Actions gives every single OSS project for free.)

Re: I hate GitHub Actions with passion

#88

Earlier quoted context omitted.

1. Just no. Unless you are some sort of Windows shop.

If you're building for Windows, then bash is "just no", so it's either cmd/.bat, or pwsh/.ps.

I mean, if you're a Windows shop you really should be using powershell.

Re: I hate GitHub Actions with passion

#89
I think this post accurately isolates the single main issue with GitHub Actions, i.e. the lack of a tight feedback loop. Pushing and waiting for completion on what's often a very simple failure mode is frustrating.

Others have pointed out that there are architectural steps you can take to minimize this pain, like keeping all CI operations isolated within scripts that can be run locally (and treating GitHub Actions features purely as progressive enhancements, e.g. only using `GITHUB_STEP_SUMMARY` if actually present).

Another thing that works pretty well to address the feedback loop pain is `workflow_dispatch` + `gh workflow run`: you still need to go through a push cycle, but `gh workflow run` lets you stay in development flow until you actually need to go look at the logs.

(One frustrating limitation with that is that `gh workflow run` doesn't actually spit out the URL of the workflow run it triggers. GitHub claims this is because it's an async dispatch, but I don't see how there can possibly be no context for GitHub to provide here, given that they clearly obtain it later in the web UI.)

Re: I hate GitHub Actions with passion

#90
Its not Github Actions' fault but the horrors people create in it, all under the pretense that automation is simply about wrapping a GitHub Action around something. Learn to create a script in Python or similar and put all logic there so you can execute it locally and can port it to the next CI system when a new CTO arrives.
Post reply on HN