Why GitHub Actions is the Internet Explorer of CI, and why Buildkite offers a better path forward for teams that care about developer experience.
Why GitHub Actions is the Internet Explorer of CI, and why Buildkite offers a better path forward for teams that care about developer experience.
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.