20 Sep 2025 |
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 |
19 May 2021 |
| @eelco:nixos.org changed the history visibility to "world_readable" from "shared". | 15:40:14 |
| @eelco:nixos.org changed the room name to "Nix Hackers" from "Nix Development". | 15:45:04 |
| @eelco:nixos.org changed the room topic to "For people hacking on the Nix package manager itself" from "Development of the Nix package manager". | 15:45:04 |
| cransom joined the room. | 15:45:08 |
| sumner joined the room. | 15:45:19 |
| danielle joined the room. | 15:47:55 |
| aaron joined the room. | 15:54:00 |
| cransom changed their display name from casey © to cransom. | 15:56:27 |
| @eelco:nixos.org invited grahamc. | 16:02:36 |
| grahamc joined the room. | 16:02:51 |
| prusnak joined the room. | 16:03:18 |
| immae joined the room. | 16:03:29 |
| prusnak changed their display name from stick to prusnak. | 16:03:56 |
| prusnak changed their display name from prusnak to stick. | 16:04:03 |
| prusnak changed their profile picture. | 16:04:57 |
| prusnak changed their display name from stick to prusnak. | 16:05:00 |
| @eelco:nixos.orgchanged room power levels. | 16:08:46 |
| Jan Tojnar joined the room. | 16:09:00 |
| Alyssa Ross joined the room. | 16:15:10 |
| niksnut joined the room. | 16:19:51 |
| grahamc | 16:42:12 |