Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

21–30 of 347 posts

Re: I hate GitHub Actions with passion

#21

  > 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!
I mean your problem was not `build.rs` here and Makefiles did not solve it, was your logic not already in `build.rs` which was called by Cargo via GitHub Actions?

The problem was the environment setup? You couldn't get CUE on Linux ARM and I am assuming when you moved to Makefiles you removed the need for CUE or something? So really the solution was something like Nix or Mise to install the tooling, so you have the same tooling/version locally & on CI?

Re: I hate GitHub Actions with passion

#23

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…

Step 0. Stop using CI services that purposefully waste your time, and use CI services that have "Rebuild with SSH" or similar. From previous discussions (https://news.ycombinator.com/item?id=46592643), seems like Semaphore CI still offers that.

Re: I hate GitHub Actions with passion

#24

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.

That's literally point #2, but I had the same reaction as you when I first read point #1 :)

Re: I hate GitHub Actions with passion

#25

> 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! I mean your problem was not `build.rs` here and Makefiles did not solve it, was your logic not already in `build.rs` which was called by Cargo via GitHub Actions? The problem was the environment setup? You couldn't get CUE on Linux ARM and I am assuming…

[dead]

Re: I hate GitHub Actions with passion

#26

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.

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.

Re: I hate GitHub Actions with passion

#27

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…

How do you handle persistent state in your actions?

For my actions, the part that takes the longest to run is installing all the dependencies from scratch. I'd like to speed that up but I could never figure it out. All the options I could find for caching deps sounded so complicated.

Re: I hate GitHub Actions with passion

#28

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

I assume you're using the currently recommended docker-in-docker method. The legacy Gitlab way is horrible and it makes it basically impossible to run pipelines locally.

Re: I hate GitHub Actions with passion

#29
post #19

Is any of this unique to GitHub Actions that does not happen on other cloud CI platforms?

The best CI platforms let you "Rebuild with SSH" or something similar, and instead of having the cycle of "change > commit > push > wait > see results" (when you're testing CI specific stuff, not iterating on Makefiles or whatever, assuming most of it is scripts you can run both locally and in CI), you get a URL to connect to while the job is running, so you can effectively ensure manually it works, then just copy-paste whatever you did to your local sources.

Re: I hate GitHub Actions with passion

#30

> 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 basically how most other CI systems work. GitLab CI, Jenkins, Buildbot, Cirrus CI, etc. are all other systems I've used and they work this way. I find GitHub Actions abhorrent in a way that I never found a CI/CD system before...

> I find GitHub Actions abhorrent in a way that I never found a CI/CD system before...

That's just the good old Microsoft effect, they have a reverse-midas-touch when it comes to actually delivering good UX experiences.

Post reply on HN