GitHub Actions could be so much better • Hacker News Board

Re: GitHub Actions could be so much better

#171

Post by Aeolun » Sat, Sep 23, 2023, 12:40 AM UTC

jurassic wrote: post #108

Most of my frustrations with GHA arise when doing something useful conflicts with someone’s idea of security. For example, branch protection rules intended to stop devs from yoloing commits blocking me from pushing a version bump commit during a release workflow.

The lack of exceptions for actions is bizarre. And then they build repository rules or whatever, and made the same mistake again! You can at least exclude github apps now, but then you need to run all your repo actions with an app installtion key :/

Re: GitHub Actions could be so much better

#172

Post by Aeolun » Sat, Sep 23, 2023, 12:44 AM UTC

My biggest pain point is not being able to do proper ternary statements in workflows. And passing arrays to called workflows. My ‘runs-on’ statements need more than one label!

You can fake it by passing a stringified JSON object, but that’s bizarre.

Re: GitHub Actions could be so much better

#173

Post by no_wizard » Sat, Sep 23, 2023, 12:47 AM UTC

davidmurdoch wrote: post #166

EddTheSDET wrote: post #111

Earlier quoted context omitted.

How DO you debug your actions? I spend so long in the commit-action-debug-change loop it’s absurd. I agree with your point re: 2 wholeheartedly though, it makes debugging scripts so much easier too. CI should be runnable locally and GitHub actions, while supported with some tooling, still isn’t very easy to work with like that.

My GH Actions debugging usually devolves into `git commit -m "wtfqwehsjsidbfjdi"`

you could always do git commit -m "" --allow-empty

Re: GitHub Actions could be so much better

#174

Post by _nhynes » Sat, Sep 23, 2023, 12:57 AM UTC

no_wizard wrote: post #173

davidmurdoch wrote: post #166

Earlier quoted context omitted.

My GH Actions debugging usually devolves into `git commit -m "wtfqwehsjsidbfjdi"`

you could always do git commit -m "" --allow-empty

    git commit --amend --no-edit && git push -f

Re: GitHub Actions could be so much better

#175

Post by remram » Sat, Sep 23, 2023, 1:01 AM UTC

Aeolun wrote: post #170

remram wrote: post #152

Can I trigger a workflow from a different workflow yet? That seems very basic, and last time I looked I had to create a token that gives read/write access to every repo in every organization to do this. And then it didn't work because the docs for the trigger API is apparently wrong.

As long as they’re in the same repository, yeah.

Different repo same org

Re: GitHub Actions could be so much better

#176

Post by lenkite » Sat, Sep 23, 2023, 1:23 AM UTC

I wish Github Actions were Lua instead of YAML. One could use a restricted environment populated with predefined functions, a restricted set of modules and all the advantages of syntax checking and language help.

Re: GitHub Actions could be so much better

#177

Post by all2 » Sat, Sep 23, 2023, 1:25 AM UTC

EddTheSDET wrote: post #111

MoreQARespect wrote: post #24

There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…

How DO you debug your actions? I spend so long in the commit-action-debug-change loop it’s absurd. I agree with your point re: 2 wholeheartedly though, it makes debugging scripts so much easier too. CI should be runnable locally and GitHub actions, while supported with some tooling, still isn’t very easy to work with like that.

There are ways to run GHA locally. I've tried out one or two of the tools. [0]

- [0] https://github.com/nektos/act

Re: GitHub Actions could be so much better

#178

Post by kelnos » Sat, Sep 23, 2023, 1:33 AM UTC

MoreQARespect wrote: post #24

There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…

I try to do (2), but I still run into annoyances. Like I'll write a script to do some part of my release process. But then I start a new project, and realize I need that script, so I copy it into the new repo. Then I fix a bug in that script, or ad some new functionality, and I need to go and update the script in the other repo too.

Maybe this means I should encapsulate this into an action, and check it in somewhere else. But I don't really feel like that; an action is a lot of overhead for a 20-line bash script. Not to mention that erases the lack of lock-in that the script alone gives me.

I guess I could check the script into a separate utility repo, and pull it into my other repos via git submodules? That's probably the least-bad solution. I'd still have to update the submodule refs when I make changes, but that's better than copy-pasting the scripts everywhere.

Re: GitHub Actions could be so much better

#179

Post by MuffinFlavored » Sat, Sep 23, 2023, 1:40 AM UTC

MoreQARespect wrote: post #24

There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2…

> our workflow ends up being about 50-60 lines as a result and very rarely needs to be changed once you've set up.

As in, use GitHub Actions as a YAML wrapper around bash/zsh/sh scripts?

Re: GitHub Actions could be so much better

#180

Post by fijiaarone » Sat, Sep 23, 2023, 3:10 AM UTC

lijok wrote: post #134

People really need to stop writing scripts in yaml. Not to be dismissive but the issues outlined in this article, aside from that security footgun, are non-issues as soon as you start using github actions only for what it should be used - to invoke your scripts in parallel in response to an event. We've banned all but actions/checkout in our org and have a very healthy dev experience as a result. People are naturally…

Yaml is the worst possible programming language, beating out even ant’s xml abomination.

Unfortunately most of the work of GitHub actions is configuring the runners and setup data, which requires you to use lots of yaml to invoke unvetted public repositories (actions) written in JavaScript to do what is easier done as shell scripts, and then use shell scripts to workaround the limitations of actions.

State is impossible, data is even more impossible, and caching is completely broken. And if you use your own runners, GitHub actions don’t even clean up their own garbage. I suspect it’s the same on public runners, but just statistically less likely to affect you, but a potential security vulnerability.

I’ve been working 2 things:

1. A front end that crafts GHA workflow yamls from a sane configuration with common tasks baked in.

2. An event and reporting system so you can see what is happening during a workflow — not after — without having to scroll through GitHub’s hideous log output in html or download and unzip the full log.