| 17 Aug 2023 |
 @infinisil:matrix.org | cole-h: Yeah: https://github.com/NixOS/nixpkgs/pull/237439/files#diff-6e9a910bb34a3e80b226fec620fb570f84328e04d16d479d106274a3a7d81b1c | 22:04:24 |
 cole-h | I could imagine a separate workflow file that would download the most recent release from NixOS/nixpkgs-checker-thingy and just run that, no need to worry about Rust rebuilds or ofborg integration | 22:04:58 |
| @infinisil:matrix.org | Hmm that could work too | 22:05:28 |
| @infinisil:matrix.org | I do really like 4. though, the check should be able to finish within a couple seconds that way. Comparatively GitHub Actions need to always download the thing first (can't use an existing /nix/store), set up the environment, etc. | 22:07:37 |
| @infinisil:matrix.org | And having to maintain another separate repository feels unnecessary | 22:08:15 |
| cole-h | If it's published as a static binary, there's no reason it should need a Nix store :P | 22:09:17 |
| @infinisil:matrix.org | Hmm true.. | 22:09:50 |
| @infinisil:matrix.org | It's really quite a Nixpkgs specific check, so it would fit into ofborg | 22:11:09 |
| @infinisil:matrix.org | Though tbh I never liked how Nixpkgs CI isn't declared in Nixpkgs itself, that's a good reason to not do that (nor any other separate repository) | 22:13:28 |
| @infinisil:matrix.org | If I had the time for it, I'd probably make ofborg be declared in an ofborg.nix file in the Nixpkgs root, where all checks would then be declared, and ofborg just has runners to make them efficient | 22:14:59 |
| @infinisil:matrix.org | E.g. for this RFC it would be a fairly generic check that "the Nix files in directory don't reference any files outside of it" | 22:15:32 |
| @infinisil:matrix.org | * If I had the time for it, I'd probably make ofborg be declared in an ofborg.nix file in the Nixpkgs root, where all checks would then be declared, and ofborg just has runners to make them efficient and turn them into github checks | 22:16:14 |
| cole-h | I'm mostly worried about how non-trivial it would be to integrate this into the current ofborg architecture.
If my option 5 (static binary published somewhere and pulled down by GHA) doesn't work out, I agree that option 4 is probably the next best. | 22:16:30 |
| cole-h | (To be clear: I'm not against the idea, but I'd much prefer not having to integrate it into ofborg.) | 22:18:00 |
| * @infinisil:matrix.org takes a closer look at ofborg | 22:19:11 |
| cole-h | (it's a mess) | 22:19:39 |
| @infinisil:matrix.org | Oh no | 22:19:46 |
| @infinisil:matrix.org | cole-h: Is there by chance an overview of all the parts involved somewhere? | 22:21:53 |
| cole-h | No, which is why it's a mess 😔 | 22:22:50 |
| cole-h | I'm not sure even I have an internalized map of the code | 22:23:26 |
| @infinisil:matrix.org | Hmm, do you have some plan for the future of ofborg? Or just maintenance mode until somebody writes something better? | 22:23:48 |
| cole-h | Mostly the latter, but I'm hoping I'll be that "somebody" as well, some day. (Maybe over the holidays I'll be able to dedicate some time to some overdue TLC.) | 22:26:04 |
| @infinisil:matrix.org | cole-h: Do you know where the complexity comes from? Is it just overengineered or are there actually tricky problems justifying it? | 22:30:03 |
| @infinisil:matrix.org | Also I'm wondering, how many machines are working together? Is there just one beefy machine for each architecture or are there many more? | 22:34:51 |
| cole-h | Right now there is: 1 coordinator, 9 evaluators / x86_64-linux builders, 2 or 3 x86_64-darwin builders, 2 or 3 aarch64-darwin builders, and 1 aarch64-linux builder (that's beefy enough to run 16 builders on the same box) | 22:36:55 |
| cole-h | In reply to @infinisil:matrix.org
cole-h: Do you know where the complexity comes from? Is it just overengineered or are there actually tricky problems justifying it? Maybe a little of column A and a little of column B? The fact it's hard to setup for local testing (something I want to hack on at the hack day at NixCon this year) is one part, because it means the only way to truly know if something works is by deploying to prod. | 22:38:01 |
 raitobezarius | In reply to @infinisil:matrix.org
Though tbh I never liked how Nixpkgs CI isn't declared in Nixpkgs itself, that's a good reason to not do that (nor any other separate repository) Isn't this orthogonal to putting this stuff in Ofborg? | 22:38:04 |
| raitobezarius | You can have a framework to render GHA in nixpkgs, use it for nixpkgs CI | 22:38:19 |
| raitobezarius | (that'd be neat) | 22:38:23 |
| raitobezarius | And ofborg would be one of the component of that CI | 22:38:35 |
