In reply to @getchoo:matrix.org
i've done this a good number of times actually (https://github.com/getchoo/nix2workflow), but honestly...i think it might be a bit gimmicky
for me, the main friction between integrating gha with nix stuff is that it doesn't Just Work with nix - like hydra, hercules-ci, or buildbot-nix would. defining stuff with nix using json makes it a bit nicer since now i don't need to bounce between the workflow file and my nix code, but i'm still having a lot of glue code to get the two working, so i don't think it really solves that core problem, just makes it slightly less bad.
(sidenote: it's also obviously not a requirement of this concept, but anecdotally i've found ci to become pretty slow with the one job -> one attribute setup that i see most people use with it, unless it's a ton of heavy packages that don't share any dependencies)
nowadays i really think a good way to go for running nix stuff in gha is a simple nix flake check. it's basically what buildbot-nix does, doesn't really require any glue code, doesn't waste extra jobs/runners for each attribute, is easily reproducible locally, and should be even better once https://github.com/NixOS/nix/pull/13998 lands in a release
Also I wasn’t suggesting a matrix per one attribute. We should build components (all libs, unit tests + functional tests) only once per matrix job, otherwise it’s too slow. A matrix of nixos tests might be nice though once the cli is built