Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

291–300 of 347 posts

Re: I hate GitHub Actions with passion

#291

Earlier quoted context omitted.

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.

I've often thought about this. There are times I would rather have CI run locally, and use my PGP signature to add a git note to the commit. Something like: ``` echo "CI passed" | gpg2 --clearsign --output=- | git notes add -F- ``` Then CI could check git notes and check the dev signature, and skip the workflow/pipeline if correctly signed. With more local CI, the incentive may shift to buying devs fancier machines i…

"Works on my machine!"

Re: I hate GitHub Actions with passion

#292

Earlier quoted context omitted.

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.

I've often thought about this. There are times I would rather have CI run locally, and use my PGP signature to add a git note to the commit. Something like: ``` echo "CI passed" | gpg2 --clearsign --output=- | git notes add -F- ``` Then CI could check git notes and check the dev signature, and skip the workflow/pipeline if correctly signed. With more local CI, the incentive may shift to buying devs fancier machines i…

I think this is a sound approach, but I do see one legitimate reason to keep using a third-party CI service: reducing the chance of a software supply chain attack by building in a hardened environment that has (presumably) had attention from security people. I'd say the importance of this is increasing.

Re: I hate GitHub Actions with passion

#294
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.

Forgejo handles all of this quite well and is, in my experience, muuuch faster than GHA

Re: I hate GitHub Actions with passion

#296
post #288
post #286

Earlier quoted context omitted.

https://github.com/nektos/act Lets you run your actions locally. I've had significant success with it for fast local feedback.

I tried this five years ago back when I was an engineer on the PyTorch project, and it didn't work well enough to be worth it. Has it improved since then?

It works well enough that I didn’t realize this wasn’t first party till right now.

Re: I hate GitHub Actions with passion

#298

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 contemplated building my own CI tool (with a local runner) and the thing is if you assume “write a pipeline that runs locally but also on push”, then the feature depth is mostly about queuing, analyzing output, and often left off, but IMO important, charting telemetry about the build history. Most of these are off the shelf, at least in some programming languages. It’s the integrations and the overmanagement whe…

I think you described Jenkins, which is infinitely better than GitHub runners.

Re: I hate GitHub Actions with passion

#299
post #288

Earlier quoted context omitted.

I tried this five years ago back when I was an engineer on the PyTorch project, and it didn't work well enough to be worth it. Has it improved since then?

It works well enough that I didn’t realize this wasn’t first party till right now.

It works, but there are fair amount of caveats, especially for someone working on things like Pytorch, the runtime is close but not the same, and its support of certain architectures etc can create annoying bugs.

Re: I hate GitHub Actions with passion

#300
post #286

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…

https://github.com/nektos/act Lets you run your actions locally. I've had significant success with it for fast local feedback.

I tried this recently and it seems like you have to make a lot of decisions to support Act. It in no way "just works", but instead requires writing actions knowing that they'll run on Act.
Post reply on HN