The Pain That is Github Actions

- Everything that goes into `main` must pass all tests. - Trivial mistakes (formatting, unused deps, lint issues) should be fixed automatically, not cause failures. - The artifacts we test with in CI should be the exact ones we release. - CI should complete quickly (to keep developers happy). GitHub Actions technically allows all of this—but setting it up is a frustrating mess, full of hidden gotchas, inconsistent behavior, and a debugging experience that makes me question my choices. … This is just one of many instances which I believe is the root of what makes the github actions security model so obscure: there are too many pitfalls accompanied by exceptions that you have to account for. Clearly the system is very powerful and allows you to do many things but it also expands the attack surface for breaking things. As far as I can tell I'm not alone in this. Another instance of the same problem I ran into is when I read this paragraph where they recommend that you don't use self-hosted runners in public repositories: … ### Docker and Github Actions, an Unholy Combination If you thought GitHub Actions was bad, try mixing in Docker. GitHub lets you run jobs inside a container. This is great in theory—you can prepackage dependencies into a dev container instead of installing them every run. In practice: - File permissions break constantly. A container builds files as one user, but GitHub runners may use another (different uid and gid) to run it. So it may be unable to either access the files in the container or in the github workspace and temporary host directories that get mounted. - The