Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

191–200 of 347 posts

Re: I hate GitHub Actions with passion

#191

Earlier quoted context omitted.

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

Whata the killer benefit of nix over, like, a docker file or a package.lock or whatever?

package.lock is JSON only, Nix is for the entire system, similar to a Dockerfile

Nix specifies dependencies declaritively, and more precisely, than Docker (does by default), so the resulting environment is reproducibly the same. It caches really well and doubles as a package manager.

Despite the initial learning curve, I now personally prefer Nix's declarative style to a Dockerfile

Re: I hate GitHub Actions with passion

#192
post #83

Earlier quoted context omitted.

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

there is quickemu which can install mac vm on linux (or any other host) rather quickly, what are your thoughts on it (I am an absolute quickemu shill because I love that software) https://github.com/quickemu-project/quickemu [ Quickly create and run optimised Windows, macOS and Linux virtual machines ]

Thank you so much for this... If I could +1 a dozen times I would.

Re: I hate GitHub Actions with passion

#193

Earlier quoted context omitted.

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.

Gemini/ChatGPT help (a lot) when getting going. They make up for the poor documentation

Re: I hate GitHub Actions with passion

#194
post #64
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. IME this is where all the issues lie. Our CI pipeline can push to a remote container registry, but we can't do this locally. CI uses wildly different caching strategies to local builds, which diverges. Breaking up builds into different steps means that you need to "stash" the output of stages somewhere. If all your CI does is `make test && make…

Ironically, at least for a couple recent projects... just installing dependencies fresh is as fast on GH Actions as the GH caching methods, so I removed the caching and simplified the workflows.

Re: I hate GitHub Actions with passion

#195
As a founder of Depot [0], where we offer our own faster and cheaper GitHub Actions runners, I can assure everyone that this feeling is the majority and not the minority.

Sounds strange to say as someone who has a product that is built around making GitHub Actions exponentially faster to close these feedback loops faster.

But I can honestly say it's only really possible because the overall system with GitHub Actions is so poor. We discover new bottlenecks in the runner and control plane weekly. Things that you'd think would be simple are either non-existent, don't work, or have terrible performance.

I'm convinced there are better ways of doing things, and we are actively building ideas in that realm. So if anybody wants to learn more or just have a therapy session about what could be better with GitHub Actions, my email is in my bio.

[0] https://depot.dev/

Re: I hate GitHub Actions with passion

#197

Earlier quoted context omitted.

Huh? Who cares if the script is .sh, .bash, Makefile, Justfile, .py, .js or even .php? If it works it works, as long as you can run it locally, it'll be good enough, and sometimes it's an even better idea to keep it in the same language the rest of the project is. It all depends and what language a script is made in shouldn't be considered a "smell".

Once you get beyond shell, make, docker (and similar), dependencies become relevant. At my current employer, we're mostly in TypeScript, which means you've got NPM dependencies, the NodeJS version, and operating system differences that you're fighting with. Now anyone running your build and tests (including your CI environment) needs to be able to set all those things up and keep them in working shape. For us, that i…

I use to have my Makefile call out and do `docker build ...` and `docker run ...` etc with a volume mount of the source code to manage and maintain tooling versions etc.

It works okay, better than a lot of other workflows I have seen. But it is a bit slow, a bit cumbersome(for langs like Go or Node.js that want to write to HOME) and I had some issues on my ARM Macbook about no ARM images etc.

I would recommend taking a look at Nix, it is what I switched to.

* It is faster. * Has access to more tools. * Works on ARM, X86 etc.

Re: I hate GitHub Actions with passion

#199

You should try RWX! You can trigger runs from the CLI for way faster feedback loops. The automatic caching is surprisingly good too. https://www.rwx.com/

Thanks for the shoutout!

If anyone has any questions or wants to give it a shot, I work at RWX and would be happy to chat more about it!

Re: I hate GitHub Actions with passion

#200
post #98
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.

I think in this case they hate the fact that they cannot easily SSH into the failing VM and debug from there. Like "I have to edit my workflow, push it, wait for it to run and fail, and repeat".

I had the weirdest thing happen a few days ago.. and only seemed to be happening in the GH runner for a PR.... somehow a function was duplicated in the action runner, and not in local or anwhere else... no idea how the corruption happened... it literally took me hours or pushing minor changes to try to correct the issue... I finally cat'd that file contents out and yep, the function was duplicated... no idea how. Had to create a new branch, copy the changes and then it worked.|

Still no idea what happened or how to ever fix/prevent it again.

Post reply on HN