| 19 Sep 2025 |
 Philip Taron (UTC-8) | Is there some "release process" to nix.dev that was missed in the 2.31 cycle? | 23:27:42 |
 Sergei Zimmerman (xokdvium) | https://github.com/NixOS/nix.dev/pull/1166 | 23:35:24 |
| Philip Taron (UTC-8) | ty, I am going to apply for commit access to nix.dev on the org site then | 23:43:03 |
 Winter | not a clue why those jobs aren’t running | 23:43:59 |
| Philip Taron (UTC-8) | As I read it, no one has pushed the merge button? | 23:48:52 |
| Winter | none of the required status checks have passed | 23:49:40 |
| Winter | so even if i press the button, it won’t work | 23:49:51 |
| Winter | (as someone with theoretical button pressing powers) | 23:50:06 |
| Winter | * | 23:50:21 |
| Philip Taron (UTC-8) | Close and reopen as Robert suggests? | 23:52:29 |
| Philip Taron (UTC-8) | https://github.com/NixOS/org/issues/170 | 23:54:06 |
| 20 Sep 2025 |
| Winter | i’m going to try that as it is a noop | 00:00:00 |
| Winter | yay! | 00:00:32 |
| Winter | Sergei Zimmerman (xokdvium) as the nix team member sounds right now, do you mind if i press the button once ci passes | 00:01:45 |
| Winter | * @xokdvium:matrix.org as the nix team member around right now, do you mind if i press the button once ci passes | 00:01:52 |
 getchoo | In reply to @xokdvium:matrix.org
I would love to do this! Since I’m done with ASAN changes I’d love to work making the CI suck less. Would you like to pair up on this? definitely :)
i was thinking of tackling the weird platform specific workflow files first. not sure where you’d want to go from there | 00:21:08 |
| Sergei Zimmerman (xokdvium) | In reply to @getchoo:matrix.org
definitely :)
i was thinking of tackling the weird platform specific workflow files first. not sure where you’d want to go from there 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 | 00:25:17 |
| Sergei Zimmerman (xokdvium) | In reply to @winter:catgirl.cloud
@xokdvium:matrix.org as the nix team member around right now, do you mind if i press the button once ci passes Sure | 00:25:57 |
| Philip Taron (UTC-8) | hell yeah it's there now | 00:33:31 |
| getchoo | 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
| 01:29:35 |
| Sergei Zimmerman (xokdvium) | That’s not a very good approach when it comes to memory usage. CI used to do it and it was atrocious. Also we want to test much more than what is exposed in flake outputs (the ones that flake check will build). There’s some intersection with hydraJobs, but only some. | 05:37:08 |
| Sergei Zimmerman (xokdvium) | Like this will only work for toy examples. | 05:39:16 |
| Sergei Zimmerman (xokdvium) | Flake check is a fundamentally broken command IMO. It leaks memory all over the place that is very much necessary for doing useful things like compiling C++ | 05:41:39 |
| Sergei Zimmerman (xokdvium) | 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 | 05:55:22 |
|  Hierophilos removed their profile picture. | 21:35:53 |
| Hierophilos set a profile picture. | 21:37:09 |
| Hierophilos changed their profile picture. | 21:42:19 |
| Hierophilos removed their profile picture. | 21:42:53 |
| Hierophilos set a profile picture. | 21:43:56 |
 fzakaria | Hi! | 21:46:56 |
