Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

11–20 of 347 posts

Re: I hate GitHub Actions with passion

#11

> For the love of all that is holy, don’t let GitHub Actions > manage your logic. Keep your scripts under your own damn > control and just make the Actions call them! The pain is real. I think everyone that's ever used GitHub actions has come to this conclusion. An ideal action has 2 steps: (1) check out the code, (2) invoke a sane script that you can test locally. Honestly, I wonder if a better workflow definition w…

This is how we did things with Jenkins and gitlab runners before, idk why folks would do it differently for GHA.

If you can't run the same scripts locally (minus external hosted service/API) then how do you debug them w/o running the whole pipeline?

Re: I hate GitHub Actions with passion

#12
Of all the valid complaints about Github Actions or CI in general, this seems to be an odd one. No details about what was tried or not tried, but hard to see a `-run: go install cuelang.org/go/cmd/cue@latest` step not working?

Re: I hate GitHub Actions with passion

#13
So the article is about the frustrating experience of fixing GitHub Actions when something goes wrong, especially when a workflow only fails on one platform, potentially due to how GitHub runner is set up (inconsistently across platforms).

Took me a while to figure that out. While I appreciate occasional banters in blog articles, this one seems to diverge into rant a bit too much, and could have made its point much clearer, with, for example, meaningful section headers.

Re: I hate GitHub Actions with passion

#14
A lot of the pain of GitHub Actions gets much better using tools like action-tmate: https://github.com/mxschmitt/action-tmate

As soon as I need more than two tries to get some workflow working, I set up a tmate session and debug things using a proper remote shell. It doesn't solve all the pain points, but it makes things a lot better.

Re: I hate GitHub Actions with passion

#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, echo out the version of whatever. You don't need it _now_, but your future self will thank you when you do it need it.

5. Consider using third party runners that have better debugging capabilities

Re: I hate GitHub Actions with passion

#16

I actually built the last thing last weekend weirdly enough. gg watch action Finds the most recent or currently running action for the branch you have checked out. Among other things. https://github.com/frankwiles/gg

Oh this is excellent. This is everything I wanted the `gh` cli to be, thanks.

edit: Just a quick note, the `gg` and `gg tui` commands for me don't show any repos at all, the current context stuff all works perfectly though.

Re: I hate GitHub Actions with passion

#17
post #3

> Now of course, in some Perfect World, GitHub could have a local runner with all the bells and whistles. Not by GitHub, but isn't act supposed to be that? https://github.com/nektos/act

Prefacing this with the fact that act is great, however, it has many shortcomings. Too often I've run into roadblocks, and when looking up the issue for it, it seems they are hard to address. Simpler workflows work fine with it, but more complex workflows will be much harder.

Don't put your logic in proprietary tooling. I have started writing all logic into mise tasks since I already manage the tool dependencies with mise. I tend to write them in a way where it can easily take advantage of GHA features such as concurrency, matrixes, etc. But beyond that, it is all running within mise tasks.

Re: I hate GitHub Actions with passion

#18

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…

I would disagree with 1. if you need anything more than shell that starts to become a smell to me. The build/testing process etc should be simple enough to not need anything more.

Re: I hate GitHub Actions with passion

#20

A lot of the pain of GitHub Actions gets much better using tools like action-tmate: https://github.com/mxschmitt/action-tmate As soon as I need more than two tries to get some workflow working, I set up a tmate session and debug things using a proper remote shell. It doesn't solve all the pain points, but it makes things a lot better.

Tmate is not available anymore, and will be fully decommissioned[0]. Use upterm[1] and action-upterm[2] instead.

Honestly, this should be built into GitHub Actions.

[0] https://github.com/tmate-io/tmate/issues/322

[1] https://upterm.dev/

[2] https://github.com/marketplace/actions/debug-with-ssh

Post reply on HN