Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I hate GitHub Actions with passion

xlii.space

Post reply on HN
Print view View original

31–40 of 347 posts

Re: I hate GitHub Actions with passion

#31

Post by embedding-shape »

ufo wrote: post #27
1a527dd5 wrote: post #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, 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.

> How do you handle persistent state in your actions?

You shouldn't. Besides caching that is.

> All the options I could find for caching deps sounded so complicated.

In reality, it's fairly simple, as long as you leverage content-hashing. First, take your lock file, compute the sha256sum. Then check if the cache has an artifact with that hash as the ID. If it's found, download and extract, those are your dependencies. If not, you run the installation of the dependencies, then archive the results, with the ID set to the hash.

It really isn't more to it. I'm sure there are helpers/sub-actions/whatever Microsoft calls it, for doing all of this with 1-3 lines or something.

Re: I hate GitHub Actions with passion

#32

Post by plagiarist »

ufo wrote: post #27
1a527dd5 wrote: post #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, 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.

If you are able to use the large runners, custom images are a recent addition to what Github offers.

https://docs.github.com/en/actions/how-tos/manage-runners/la...

Re: I hate GitHub Actions with passion

#33

Post by embedding-shape »

dijit wrote: post #26
Storment33 wrote: post #18

Earlier quoted context omitted.

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.

> If your CI can do things that you can't do locally: that is a problem.

Probably most of the times when this is an actual problem, is building across many platforms. I'm running Linux x86_64 locally, but some of my deliverables are for macOS and Windows and ARM, and while I could cross-compile for all of them on Linux (macOS was a bitch to get working though), it always felt better to compile on the hardware I'm targeting.

Sometimes there are Windows/macOS-specific failures, and if I couldn't just ssh in and correct/investigate, and instead had to "change > commit > push" in an endless loop, it's possible I'd quite literally would lose my mind.

Re: I hate GitHub Actions with passion

#34

Post by 1a527dd5 »

ufo wrote: post #27
1a527dd5 wrote: post #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, 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.

You don't.

For things like installing deps, you can use GitHub Actions or several third party runners have their own caching capabilities that are more mature than what GHA offers.

Re: I hate GitHub Actions with passion

#35

Post by Storment33 »

embedding-shape wrote: post #24
Storment33 wrote: post #18

Earlier quoted context omitted.

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 :)

I agree with #2, I meant more if you are calling out to something that is not a task runner(Make, Taskfile, Just etc) or a shell script thats a bit of a smell to me. E.g. I have seen people call out to Python scripts etc and it concerns me.

Re: I hate GitHub Actions with passion

#36

Post by Storment33 »

dijit wrote: post #26
Storment33 wrote: post #18

Earlier quoted context omitted.

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.

> If your CI can do things that you can't do locally: that is a problem.

Completely agree.

> I'm a huge fan of "train as you fight", whatever build tools you have locally should be what's used in CI.

That is what I am doing, having my GitHub Actions just call the Make targets I am using locally.

> I mean, at some point you are bash calling some other language anyway.

Yes, shell scripts and or task runners(Make, Just, Task etc) are really just plumbing around calling other tools. Which is why it feels like a smell to me when you need something more.

Re: I hate GitHub Actions with passion

#37

Post by frankwiles »

drcongo wrote: post #16
frankwiles wrote: post #5

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.

Ah sorry need to make the docs more clear. You need to run ‘gg data refresh’ to populate the local DB first.

Re: I hate GitHub Actions with passion

#38

Post by never_inline »

1a527dd5 wrote: post #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, e…

Build a CLI in python or whatever which does the same thing as CI, every CI stage should just call its subcommands.

Re: I hate GitHub Actions with passion

#40

Post by thewhitetulip »

Until I resd this blog I was under the impression that everyone wrote Python/ other files and used Github Actions to just call the scripts!

This way we can test it on local machine before deployment.

Also as other commenters have said - bash is not a good option - Use Python or some other language and write reusabe scripts. If not for this then for the off chance that it'll be migrated to some other cicd platform

Post reply on HN