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

241–250 of 347 posts

Re: I hate GitHub Actions with passion

#241

Post by maliker »

themafia wrote: post #239
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 just use the fact that any action run can trigger a webhook. The action does nothing other than trigger the hook. Then my server catches the hook and can do whatever I want.

I wish I had the courage to run my own CI server. But yes, I think your approach is the best for serious teams that can manage more infrastructure.

Re: I hate GitHub Actions with passion

#242

Post by olivia-banks »

At work we have a bunch of GitHub actions for integration testing, building models, publishing, reporting, and whatnot. It was horrible to maintain and look into whenever something went wrong, so I rewrote all the individual parts in Perl and hooked them together with pipes inside GHA, and it works wonders.

Also, GitHub actions itself just breaks sometimes, which is super annoying. A couple of weeks ago, half of all the macOS runner images broke when using GitHub's caching system. Seems like that would have been caught on GitHub's side before that happened, but what do I know!

> https://github.com/actions/runner/issues/449

> https://github.com/orgs/community/discussions/180160

Re: I hate GitHub Actions with passion

#243

Post by jayd16 »

linuxftw wrote: post #47
1a527dd5 wrote: post #15

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…

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

Pwsh scripts are portable across mac, linux and windows with arguably less headache than bash. Its actually really nice. You should try it.

If you don't like it, you can get bash to work on windows anyway.

Re: I hate GitHub Actions with passion

#244

Post by quotemstr »

Imustaskforhelp wrote: post #236
quotemstr wrote: post #233

Earlier quoted context omitted.

I'm a huge believer in the rule that everything GH actions does should be a script you can also run locally.

Yes I believe the same too and I think we are on the same goal. I think that I can probably patch this code to install uv, let's say locally instead of globally if that's a major concern. I feel like its not that hard.

It's easy enough to patch. It's the philosophy that bugs me. We already have a huge problem with routine workflows pulling things from the network (often, without even a semblance of hash-locking) and foregoing the traditional separation between environment setup and business logic. There's a lot of value into having discrete steps for downloading/installing stuff and doing development, because then you can pay special attention to the former, look for anything odd, read release notes, and so on. Between explicit, human-solicited upgrades, dev workflows should be using, ideally, vendored dependencies, or, if not that, then at least stuff that's hash-verified end-to-end.

Someday, someone is going to have a really big disaster that comes out of casual getting unauthenticated stuff from somebody else's computer.

Re: I hate GitHub Actions with passion

#245

Post by Atotalnoob »

shykes wrote: post #221
jgautsch wrote: post #209

Earlier quoted context omitted.

I've been watching Dagger with great interest, although have not moved production workloads to it (nor, admittedly, even committed an afternoon to setting up any workflows/graphs). Passive comment readers should be aware that ^shykes here cofounded Docker (my gratitude), so it's really worth a look. Can anyone comment on the ergonomics of Dagger after using it for a while? I was just looking at the docs earlier this…

> got confused by the AI sections... You're not the only one... At some point last year, we discovered that CI/CD workflows and so-called "AI agent workflows" have a lot in common, and Dagger can in theory be used as an execution engine for both. We attempted to explain this - "great for CI/CD and for Agents!". But the feedback was mostly negative - it came across as confusing and lacking focus. So, we are rolling ba…

Do you have to use discord? All that information is locked away in a vendors system. Why not choose an open source chat app?

Re: I hate GitHub Actions with passion

#246

Post by mmcnl »

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…

But very often the CI operations _are_ the problem. It's just YAML files with unlimited configuration options that have very limited documentation, without any type of LSP.

Re: I hate GitHub Actions with passion

#247

Post by cadamsdotcom »

So many engineers could put the hours spent debugging GH actions to use developing expertise to run their own CI. But people either don’t believe they can, can’t convince decision makers to let them try, or just want to fix their own problem and move on.

I was convinced GH actions was best practice and it was normal to waste hours on try-and-pray build debugging, until one day GH actions went down and I ran deploys from my laptop and remembered how much better life can be without it..

(Solo dev here - but opensource CI on an EC2 instance can be just as nice)

Re: I hate GitHub Actions with passion

#248

Post by jcgl »

palata wrote: post #141
Nextgrid wrote: post #133

Earlier quoted context omitted.

Self-hosted runners with Github is a whole world of pain because it literally just runs commands on the host and does not handle provisioning/cleanup, meaning you need to make sure your `docker run` commands don't leave any leftover state that can mess up future/concurrent builds. It doesn't even handle concurrency by itself, so you have to run multiple instances of the runner.

That was included in my "but then you have to self-host" :-). As I said, I really like the SourceHut CI.

Do you have any experience self-hosting SourceHut? I’d really like to do so, but I get weak knees every time I look at the docs for it.

Re: I hate GitHub Actions with passion

#249

Post by watermelon0 »

Nextgrid wrote: post #133
palata wrote: post #96

Earlier quoted context omitted.

I really like the SourceHut CI, because: 1. When the build fails, you can SSH into the machine and debug it from there. 2. You can super easily edit & run the manifest without having to push to a branch at all. That makes it super easy to even try a minimum reproducible example on the remote machine. Other than that, self-hosting (with Github or preferrably Forgejo) makes it easy to debug on the machine, but then you…

Self-hosted runners with Github is a whole world of pain because it literally just runs commands on the host and does not handle provisioning/cleanup, meaning you need to make sure your `docker run` commands don't leave any leftover state that can mess up future/concurrent builds. It doesn't even handle concurrency by itself, so you have to run multiple instances of the runner.

Github supports ephemeral runners which are limited to a single job.

You can use `workflow_job` webhook to be notified of a new job, after that you need to call `generate-jitconfig` API to get a just-in-time configuration token, and then you can start a Github runner in ephemeral mode with the JIT token.

This allows you to orchestrate Docker containers, KVM instances, etc., which are used for a single time, and then destroyed.

There are some open source projects, such as using ephemeral Kubernetes pods with the ephemeral runners.

Re: I hate GitHub Actions with passion

#250

Post by Mattwmaster58 »

spockz wrote: 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.

It's generally very helpful - someone else mentioned here the fundamental problem is lack of a tight feedback loop. It doesn't perfectly replicate the GH environment, but for my use case that doesn't matter and it's super nice to have.
Post reply on HN