| 17 Aug 2023 |
 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 |
| raitobezarius | And the rfc140 checker maybe another in option 5 | 22:38:46 |
| @infinisil:matrix.org | Not sure what you mean | 22:38:49 |
| cole-h | In reply to @raitobezarius:matrix.org
Isn't this orthogonal to putting this stuff in Ofborg? (Fwiw, I read that as "maybe it would be better to keep the program in Nixpkgs", not something else) | 22:39:10 |
| @infinisil:matrix.org | I don't think you can render a GHA config? | 22:39:14 |
| raitobezarius | GHA workflow is a YAML file | 22:39:35 |
| cole-h | If only GHA was like buildkite... | 22:40:15 |
| @infinisil:matrix.org | Ah I think Isee | 22:40:20 |
| raitobezarius | I meant to render GHA workflows via Nix expressions | 22:40:31 |
| @infinisil:matrix.org | So you use something like ofborg to turn some ofborg.nix into a .github/workflows | 22:40:32 |
| * raitobezarius nods | 22:40:40 |
| @infinisil:matrix.org | In reply to @cole-h:matrix.org
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. Hmm right.. | 22:40:58 |
| raitobezarius | Well I am not exactly certain whether you update generated files inside the repo or have it dynamic or whatever (yeah @ buildkite) | 22:41:11 |
| raitobezarius | But that's definitely something that seems interesting to pursue | 22:41:32 |
 Lily Foster | In reply to @raitobezarius:matrix.org
GHA workflow is a YAML file I mean JSON is a subset of YAML 1.2 so you could just use Nix's builtin toJSON too 👀 | 22:41:49 |
| raitobezarius | And we can probably have higher level abstractions specific to nixpkgs CI inside github | 22:42:23 |
