| 14 May 2024 |
 samrose | you can't do that in a container in any case can you? | 00:48:22 |
 raitobezarius | Orthogonal, you can do it in a container, but it doesn't seem like Cirrus has a phase where you tell it "ok spawn me N containers and make them do this and that" | 00:49:07 |
| raitobezarius | Thus it's necessarily serial inside of that container or you statically list all your targets as you change them | 00:49:28 |
| samrose | I see | 00:49:30 |
| raitobezarius | Plus the container means you go from clean Nix store and you need to redownload stuff | 00:50:00 |
| raitobezarius | Or you need to build some hot container, push it to registry and load it in the CI | 00:50:14 |
| raitobezarius | Whereas current model share the Nix store and GC it as it go | 00:50:28 |
| samrose | so the optimal way would be to have the actual hardware, and be running nix-eval-jobs and just let nix do it's thing + retain the store basically like the way many people have used hydra in the past | 00:51:12 |
| raitobezarius | I'd say so, right now, an improvement would be to go to something like Hydra New Generation | 00:51:56 |
| samrose | it doesn't sound like it would be a lot of fun to maintain building this in containers the way you describe it | 00:52:00 |
| raitobezarius | In reply to @samrose:matrix.org
it doesn't sound like it would be a lot of fun to maintain building this in containers the way you describe it Hahahahahahaha :-) | 00:52:13 |
| samrose | I mean, not that I think you are wrong at all | 00:52:25 |
| raitobezarius | Oh, those are my 2 cents | 00:52:43 |
| raitobezarius | I may be wrong ofc | 00:52:48 |
| samrose | what you say makes sense given running nix-eval-jobs, and all of that | 00:53:16 |
| samrose | and it would be worth the effort to do Hydra New Generation | 00:53:29 |
| raitobezarius | But it requires to improve Lix etc etc and then dogfood further and then Hydra Ng appears | 00:53:56 |
| samrose | yes first we would need to get the bugs and issues that are pending that makes sense | 00:54:39 |
 Qyriad | (we::Lix somewhat intentionally put ourselves in our own suffering path of CI) | 00:54:55 |
| raitobezarius | In reply to @qyriad:katesiria.org
(we::Lix somewhat intentionally put ourselves in our own suffering path of CI) (this is... our bootstrap path! :>) | 00:55:17 |
| Qyriad | Lix (and Nix) sucks at this, and it makes our lives worse. improving the state of the ecosystem will make our and everyone else's lives better | 00:55:22 |
| raitobezarius | In reply to @samrose:matrix.org
yes first we would need to get the bugs and issues that are pending that makes sense There's also some critical performance improvements on the scheduling side of things | 00:55:36 |
| raitobezarius | Maybe my dumb view on this is I need to get an Ampere Altra Q80-30 somewhere, wire this up to gigabit (or even 100mbps) and then we get faster CI to some extent | 00:56:36 |
| raitobezarius | Then there's things like balancing out aarch64 capacity between Darwin and Linux | 00:56:54 |
| raitobezarius | Then there's things like improving scheduling as a whole | 00:57:16 |
| raitobezarius | Etc etc | 00:57:17 |
| samrose | In reply to @raitobezarius:matrix.org
There's also some critical performance improvements on the scheduling side of things here you are referring to the scheduling of ci builds is that right? | 00:57:39 |
| raitobezarius | In reply to @samrose:matrix.org
here you are referring to the scheduling of ci builds is that right? More generally how a Nix aware CI component will decide to place a build on a piece of compute (policy, binpacking, etc.) | 00:58:37 |
| raitobezarius | It can be Nix scheduler, can be Hydra scheduler, there's multiple possible designs and paths | 00:59:03 |
| samrose | hmm, so like you envision that this ci component might become part of nix or hydra I see | 00:59:12 |
