Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

Post reply on HN
Print view View original

151–160 of 347 posts

Re: I hate GitHub Actions with passion

#151

Post by woodruffw »

anttiharju wrote: post #136
woodruffw wrote: post #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 fe…

> i.e. the lack of a tight feedback loop. Lefthook helps a lot https://anttiharju.dev/a/1#pre-commit-hooks-are-useful Thing is that people are not willing to invest in it due to bad experiences with various git hooks, but there are ways to have it be excellent

Yeah, I'm one of those people who seems to consistently have middling-to-bad experiences with Git hooks (and Git hook managers). I think the bigger issue is that even with consistent developer tooling between both developer machines and CI, you still have the issue where CI needs to do a lot more stuff that local machines just can't/won't do (like matrix builds).

Those things are fundamentally remote and kind of annoying to debug, but GitHub could invest a lot more in reducing the frustration involved in getting a fast remote cycle set up.

Re: I hate GitHub Actions with passion

#152

Post by quotemstr »

Wilder7977 wrote: post #137
zelphirkalt wrote: post #76

Earlier quoted context omitted.

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.

For certain things, makefiles are great options. For others though they are a nightmare. From a security perspective, especially if you are trying to reach SLSA level 2+, you want all the build execution to be isolated and executed in a trusted, attestable and disposable environment, following predefined steps. Having makefiles (or scripts) with logical steps within them, makes it much, much harder to have properly a…

That doesn't make any sense. Nothing about SLSA precludes using make instead of some other build tool. Either inputs to a process are hermetic and attested or they're not. Makefiles are all about executing "predefined steps".

It doesn't matter whether you run "make test" or "npm test whatever": you're trusting the code you've checked out to verify its own correctness. It can lie to you either way. You're either verifying changes or you're not.

Re: I hate GitHub Actions with passion

#153

Post by cedws »

woodruffw wrote: post #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 fe…

I’ve never used Nix and frankly am a sceptic, but can it solve this problem by efficiently caching steps?

Re: I hate GitHub Actions with passion

#154

Post by flohofwoe »

GH Actions isn't great compared to other CI systems, but it's also not particularly worse until you get into the nitty gritty details.

The most important advice is probably to put as much code as possible into locally runnable scripts written in a cross-platform scripting language (e.g. Python or Node.js) to avoid 'commit-push-ci-failure' roundtrips.

Only use the GH Actions YAML for defining the runtime environment and job dependency tree.

Re: I hate GitHub Actions with passion

#155

Post by AmazingTurtle »

anttiharju wrote: post #144

Issue is, op is trying to use matrix strategy when with cross-compiling they could avoid it. I have done it for https://github.com/anttiharju/compare-changes (which has nontrivial CI pipelines but they could be a lot simpler for op's needs) Main issue is Rust. Writing catchy headlines about hating something may feel good, but a lot of people could avoid these pains if - zig cc gets support for new linker flag that Ru…

Ah a classic stack overflow flavored answer ala: do it differently so you don't encounter these issues

Re: I hate GitHub Actions with passion

#156

Post by flohofwoe »

Imustaskforhelp wrote: post #149

Wrote a comment to someone here but I thought of deciding to make a main comment here as well Note that I don't really use github actions much but have heard about its architecture From my understanding, I feel like Github actions should just be a call to some bash or python file. Bash has its issues so I prefer python I recommend people to take a look at https://paulw.tokyo/standalone-python-script-with-uv/ and plea…

> I feel like Github actions should just be a call to some bash or python file. Bash has its issues so I prefer python

...and that's how it is supposed to be used. The YAML file is mainly there for defining the runtime environment (e.g. the operating system or docker image to run in), and to describe the job dependency tree. The actual actions to execute should be delegated to scripts outside the GH YAML.

Re: I hate GitHub Actions with passion

#157

Post by maliker »

steeleduncan wrote: post #139
maliker wrote: post #110

Earlier quoted context omitted.

I've standardized on getting github actions to create/pull a docker image and run build/test inside that. So if something goes wrong I have a decent live debug environment that's very similar to what github actions is running. For what it's worth.

I do the same with Nix as it works for macOS builds as well It has the massive benefit of solving the lock-in problem. Your workflow is generally very short so it is easy to move to an alternative CI if (for example) Github were to jack up their prices for self hosted runners... That said, when using it in this way I personally love Github actions

I'm scared by all these references to nix in the replies here. Sounds like I'm going to have learn nix. Sounds hard.

Re: I hate GitHub Actions with passion

#158

Post by tagraves »

woodruffw wrote: post #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 fe…

This is one of the big problems we solved with the RWX CI platform (RWX.com). You can use ‘rwx run’ and it automatically syncs your local changes, so no need to push — and with our automated caching, steps like setting up the environment cache hit so you don’t have to execute the same stuff over and over again while writing your workflow. Plus with our API or MCP server you can get the results directly in your terminal so no need to open the UI at all unless you want to do some in-depth spelunking.

Re: I hate GitHub Actions with passion

#160

Post by goodpoint »

smetj wrote: post #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.

It's 100% GA's fault and they do it on purpose.
Post reply on HN