Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

251–260 of 347 posts

Re: I hate GitHub Actions with passion

#251

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…

#2 is not a slam dunk because the CI system loses insight into your build process if you just use one big script.

Does anyone have a way to mark script sections as separate build steps with defined artifacts? Would be nice to just have scripts with something like.

    BeginStep("Step Name") 
    ... 
    EndStep("Step Name", artifacts)
They could noop on local runs but be reflected in the github/gitlab as separate steps/stages and allow resumes and retries and such. As it stands there's no way to really have CI/CD run the exact same scripts locally and get all the insights and functionality.

I haven't seen anything like that but it would be nice to know.

Re: I hate GitHub Actions with passion

#252
> A word of explanation. I’m building tmplr for 4 platforms:

   > Linux ARM
   > macOS ARM
   > Linux x86_64
   > macOS x86_64
Oh, here we go again. Java was invented to solve that, "Write once run everywhere" :] I.e. `int` means `i32` on all platforms, no `usize`.

Re: I hate GitHub Actions with passion

#253

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 am embarrassed that I didn't think to do this. Thank you :)

Re: I hate GitHub Actions with passion

#254

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

Nix is so nice that you can put almost your entire workflow into a check or package. Like your code-coverage report step(s) become a package that you build (I'm not brave enough to do this)

I run my own jenkins for personal stuff on top of nixos, all jobs run inside devenv shell, devenv handles whatever background services required (i.e. database), /nix/store is shared between workers + attic cache in local network.

Oh, and there is also nixosModule that is tested in the VM that also smoke tests the service.

First build might take some time, but all future jobs run fast. The same can be done on GHA, but on github-hosted runners you can't get shared /nix/store.

Re: I hate GitHub Actions with passion

#255

Earlier quoted context omitted.

It's interesting because #1 is still suggesting a shell script, it's just suggesting a better shell to script.

I had no idea 'pwsh' was PowerShell. Personally not interested, maybe if your a Microsoft shop or something then yeah.

It's actually a pretty good shell! FOSS and cross-platform, too.

Re: I hate GitHub Actions with passion

#256
post #248
post #141

Earlier quoted context omitted.

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.

I don't, but I would be curious.

But I'm happy to contribute (money) to SourceHut, they're doing a good job.

Re: I hate GitHub Actions with passion

#257
post #221

Earlier quoted context omitted.

> 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?

What alternatives would you recommend?

Re: I hate GitHub Actions with passion

#258

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…

It's insane to me that being able to run CI steps locally is not the first priority of every CI system. It ought to be a basic requirement.

This goes against every incentive for the CI service provider

Re: I hate GitHub Actions with passion

#259

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 f…

> So many engineers could put the hours spent debugging GH actions to use developing expertise to run their own CI.

If I run my own CI, then the compliance team has to get involved to run various endpoint security and update management tools on whatever system I'm running the CI on.

Post reply on HN