82
GitHub Actions Is Slowly Killing Your Engineering Team - Ian Duncan
(www.iankduncan.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 27 Mar 2026
82 points (93.6% liked)
Programming
26276 readers
259 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
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.