| 29 Dec 2024 |
 emily | lovely | 20:29:45 |
 Janne Heß | Yeah, huge fun | 20:29:52 |
| emily | perhaps it could be inverted, though? the GHA could notify ofborg. | 20:29:58 |
| emily | no passive scanning | 20:30:08 |
| Janne Heß | Sounds like an interesting idea, yeah | 20:30:26 |
| Janne Heß | But I'll be honest I will try to get it working as much as possible in the current state and then revisit it in a couple of months since I'm extremely sick of it by now | 20:30:54 |
| emily | not that I mind the idea of ofborg driving things either. especially if the other CI stuff can be folded into it | 20:31:13 |
| emily | understandable | 20:31:22 |
| Janne Heß |
Dec 29 20:31:01 ofborg-eval01 mass-rebuilder[274604]: 2024-12-29T20:31:01.016214Z INFO ofborg::tasks::evaluate: Scheduling build jobs [BuildJob { repo: Repo { owner: "ofborg", name: "testpkgs", full_name: "ofborg/testpkgs", clone_url: "https://github.com/ofborg/testpkgs.git" }, pr: Pr { target_branch: Some("master"), number: 1, head_sha: "87b7f8211480a9b959307810c54022acd5ecb559" }, subset: Some(Nixpkgs), attrs: ["coreutils", "coreutils.passthru.tests", "hello", "hello.passthru.tests"], request_id: "2a070123-d747-4f77-978e-0662a2f06eaf", logs: Some((Some("logs"), Some("ofborg/testpkgs.1"))), statusreport: Some((Some("build-results"), None)) }] on arches [X8664Darwin, X8664Linux, Aarch64Darwin, Aarch64Linux]
| 20:32:11 |
| Janne Heß | YES, it evaled | 20:32:15 |
| emily | I always heard that there's no real way to test ofborg changes other than running it in prod, is that still true? | 20:32:40 |
| Janne Heß | Yep, one of the pain points :D | 20:32:50 |
| Janne Heß | It's alwys nvim && cargo c && nix flake lock && colmena apply | 20:33:03 |
| emily | I guess it shares that with GHA to some degree tbf :) | 20:33:03 |
| emily | yuck | 20:33:10 |
| emily | I admire your persistence | 20:33:15 |
| Janne Heß | Yes unfortunately | 20:33:17 |
| Janne Heß | I regret it :D | 20:33:23 |
| emily | GHA at least has the docs / tooling / approachability advantage, I suppose, in terms of future directions for what we want to drive CI | 20:34:05 |
| emily | too bad about the lock-in | 20:34:10 |
| Janne Heß | Yeah, that's my exact opinion. But if we are being honest, how likely are we to ever break out of that lock-in? | 20:35:25 |
| emily | well, 0 likely if we use that reasoning at all key turning points :) | 20:37:34 |
| emily | the GitHub UX causes me pain every single day I do Nixpkgs stuff, so I would personally be very happy if we got Gerrit or something. but yeah, I don't know if it's a lost cause or not. | 20:37:59 |
| Janne Heß | It is imo | 20:38:29 |
 7c6f434c | >0% of just eventually getting forced out for one reason or another… | 20:38:41 |
| emily | eh, it's not hard for me to imagine a world where we have {gitlab,forgejo}.nixos.org with GH login. I think at least one or two people on the steering committee indicated they were interested in pushing in that direction | 20:40:06 |
| 7c6f434c | (like, some CI limit gets restructured) | 20:39:11 |
| emily | unfortunately it's precisely non-GH-cloning code review UI that I'd like. but even GitLab/Forgejo would require some CI re-engineering. | 20:40:26 |
| emily | ideally we'd have relatively thin GHA wrappers around more agnostic tooling | 20:40:39 |
| Janne Heß | That's what the Lix people are doing with ofborg afaik. We'll see how that goes | 20:41:36 |
