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

231–240 of 347 posts

Re: I hate GitHub Actions with passion

#231

Post by zelphirkalt »

Wilder7977 wrote: post #214
quotemstr wrote: post #152

Earlier quoted context omitted.

That doesn't make any sense. Nothing about SLSA precludes using make instead of some other build tool. Either inputs to a process are hermetic and attested or they're not. Makefiles are all about executing "predefined steps". It doesn't matter whether you run "make test" or "npm test whatever": you're trusting the code you've checked out to verify its own correctness. It can lie to you either way. You're either verif…

You haven't engaged with what I wrote, of course it doesn't make sense. The easiest and most accessible way to attest what has been done is to have all the logic of what needs to be done in a single context, a single place. A reusable workflow that is executed by hash in a trusted environment and will execute exactly those steps, for example. In this case, step A does x, and step B attests that x has been done, becau…

Usually, the people writing the Makefile are the same that could also be writing this stuff out in a YAML (lol) file as the CI instructions, often located in the same repository anyway. The irony in that is striking. And then we have people who can change environment variables for the CI workflows. Usually, also developers, often the same people that can commit changes to the Makefile.

I don't think it changes much, aside from security theater. If changes are not properly reviewed, then all fancy titles will not help. If anything, using Make will allow for a less flaky CI experience, that doesn't break the next time the git hoster changes something about their CI language and doesn't suffer from YAMLitis.

Re: I hate GitHub Actions with passion

#232

Post by zelphirkalt »

arwhatever wrote: post #218
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…

Do you (or does anyone) see possible value in a CI tool that just launches your script directly? It seems like if you > 2. Don't have logic in your workflows. Workflows should be dumb and simple (KISS) and they should call your scripts. then you’re basically working against or despite the CI tool, and at that point maybe someone should build a better or more suitable CI tool.

Can we have a CI tool, that simply takes a Makefile as input? Perhaps takes all targets, that start with "ci" or something.

Re: I hate GitHub Actions with passion

#233

Post by quotemstr »

Imustaskforhelp wrote: post #162
quotemstr wrote: post #148

Earlier quoted context omitted.

This thing does a global uv install when run? That's obnoxious! Never running stuff from whoever wrote this. Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software.

Does it really matter if its a global install of uv or not especially on Github Actions Also if this still bothers you, nothing stops you from removing the first x lines of code and having it in another .py file if this feels obnoxious to you > Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software. Regarding author suggest its removes i…

I'm a huge believer in the rule that everything GH actions does should be a script you can also run locally.

Re: I hate GitHub Actions with passion

#235

Post by quotemstr »

zelphirkalt wrote: post #231
Wilder7977 wrote: post #214

Earlier quoted context omitted.

You haven't engaged with what I wrote, of course it doesn't make sense. The easiest and most accessible way to attest what has been done is to have all the logic of what needs to be done in a single context, a single place. A reusable workflow that is executed by hash in a trusted environment and will execute exactly those steps, for example. In this case, step A does x, and step B attests that x has been done, becau…

Usually, the people writing the Makefile are the same that could also be writing this stuff out in a YAML (lol) file as the CI instructions, often located in the same repository anyway. The irony in that is striking. And then we have people who can change environment variables for the CI workflows. Usually, also developers, often the same people that can commit changes to the Makefile. I don't think it changes much,…

You're correct. It's absolutely security theater. Either you trust the repository contents or you don't. There's no, none, zilch trust improvement arising from the outer orchestration being done in a YAML file checked into the repo and executed by CI instead of a Makefile also executed by CI.

What's the threat model Wilder is using exactly? Look, I'm ordinarily all for nuance and saying reasonable people can disagree when it comes to technical opinions, but here I can't see any merit whatsoever to the claim that orchestrating CI actions with Make is somehow a security risk when the implementations of these actions at some level live in the repo anyway.

Re: I hate GitHub Actions with passion

#236

Post by Imustaskforhelp »

quotemstr wrote: post #233
Imustaskforhelp wrote: post #162

Earlier quoted context omitted.

Does it really matter if its a global install of uv or not especially on Github Actions Also if this still bothers you, nothing stops you from removing the first x lines of code and having it in another .py file if this feels obnoxious to you > Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software. Regarding author suggest its removes i…

I'm a huge believer in the rule that everything GH actions does should be a script you can also run locally.

Yes I believe the same too and I think we are on the same goal. I think that I can probably patch this code to install uv, let's say locally instead of globally if that's a major concern. I feel like its not that hard.

Re: I hate GitHub Actions with passion

#238

Post by modeless »

woodruffw wrote: post #89

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…

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.

Re: I hate GitHub Actions with passion

#239

Post by themafia »

maliker wrote: post #110
woodruffw wrote: post #89

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 standardized on getting github actions to create/pull a docker image and run build/test inside that. So if something goes wrong I have a decent live debug environment that's very similar to what github actions is running. For what it's worth.

I just use the fact that any action run can trigger a webhook.

The action does nothing other than trigger the hook.

Then my server catches the hook and can do whatever I want.

Re: I hate GitHub Actions with passion

#240

Post by themafia »

Nextgrid wrote: post #48

The way I deal with all these terrible CI platforms (there is no good one, merely lesser evils) is to do my entire CI process in a container and the CI tool just pulls and runs that. You can trivially run this locally when needed. Of course, the platforms would rather have you not do that since it nullifies their vendor lock-in.

Github delivers an exceptionally detailed webhook. Ironically, there is zero actual lock in, the CI/CD cargo cult is that strong they didn't even need it.
Post reply on HN