Why GitHub Actions is the Internet Explorer of CI, and why Buildkite offers a better path forward for teams that care about developer experience.
Sounds about right.
I’m using GitHub actions at work because this place is extremely dysfunctional, and I can just add GitHub actions without it being a whole “research spike planning meeting impact analysis” six week journey.
I took it from “there are absolutely no checks and Bob broke the environment because he pushed up a change that’s just invalid syntax” to… well, I couldn’t make it block the build on failures but at least now when Bob breaks it again I can point to the big red X and ask why he merged with an error.
If you can get the permissions to do it set the protected branch and prevent merge on build failures. This is a repo setting that will work with any ci provider assuming it updates the PR status.
I thought about it but people are so sensitive here. If they broke something and couldn’t merge they’d probably raise a big stink, and then there’s good odds the checks would be removed “because they’re adding friction” or some nonsense. My boss has already warned me about staying in my lane.
These people have never done any automated testing of any sort. No linter. No unit tests. And they don’t seem to want to.
Time to look for a better boss
Well, yes, though my direct manager isn’t the worst. He’s trying to protect me from other teams that might get pissy.
One of my friends is a product manager type and his analysis was basically “if stakeholders don’t care it’s not a problem, even if by any reasonable metric it is a problem”. So. Here we are.
skimmed.
preface: I do not like Microsoft or GitHub
a lot of the points I read seem like skill issue
there is validation for the yaml files, some of the criticism is correct. on occasion the error system in actions does not spit anything useful, you cannot dry run them even if you have self hosted runners
but to say it’s killing your engineering team when it’s just vibes at my work seems odd, your bad CI is killing your team maybe, but GitHub actions is not the problem
Well, I’m in that Nix shop category. For example, I run tests for my OSS project using lots of Python versions. There’s no need to use a Github Actions matrix for that - Nix does it more efficiently. Doesn’t even require containers or VMs. And the whole setup runs exactly the same locally, on Github Actions, or on Garnix. (But Garnix has better Nix caching than other CI runners, so that’s what I use.)
What’s your solution to handle secrets locally?
There are a few options:
-
Sops-nix or Agenix store secrets encrypted in the repo. Each local machine needs to be set up with a PGP or an SSH key to decrypt and encrypt as necessary. This is what I do with my NixOS configuration.
-
Manage secrets externally to repo code. I like to use direnv; sometimes I configure the checked-in
.envrcfile to source another file with secrets, that is not checked in. -
Don’t use secrets locally. If secrets are things like deploy keys, and I want all deploys going through CI, then I don’t want secrets configured locally. Instead running a deploy script locally should be a dry run, which doesn’t need secrets.
-
Generate secrets at runtime. This is for cases where the project runs a cluster of services which need to authenticate with each other. For tests with locally running test services, authentication is confined to this isolated system. So secrets can be generated at test time, and written to env or config files that are not checked in.
In your CI which one do you use? I also use SOPS for my own, but it’s overhead… So wondering which you settled on?
I use sops for NixOS, but those secrets aren’t accessed in CI. For actual CI I’ve used a combination of 2-4 above.
-
It’s better than Jenkins, no?
Yep. Ill agree to that lol.
