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

Doesn't this look like a binutils bug? At least this is very suspicious:

assertion fail ../../bfd/elf-sframe.c:140

In reply to @xokdvium:matrix.org
I had a pretty crazy idea. How about we defined the workflow matrix in Nix? GHA can read a dynamically generated matrix from JSON. That would make stuff much easier

In reply to @joerg:thalheim.io
All the implementation i found so far do not respect dependencies between jobs and also do not deduplicate aliases. They work okay for simpler flakes but get too slow for larger ones.