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 guided towards writing scripts that they can run locally instead of for github actions specifically.
Some real issues with github actions:
1. MacOS runners have ridiculously inconsistent IO performance causing 200x slowdown in some cases
2. Getting charged to the nearest minute is asinine and punishes highly parallelised (fast) workloads
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.
Some real issues with github actions:
1. MacOS runners have ridiculously inconsistent IO performance causing 200x slowdown in some cases
2. Getting charged to the nearest minute is asinine and punishes highly parallelised (fast) workloads
3. GitHub OIDC endpoints constantly timing out