| 29 Dec 2024 |
 Janne Heß | No, it's actually very easy. I get the event that some GHA check completed and it even tells me on what commit it ran. What it doesn't tell me is the PR this commit belongs to. I asked someone from the merge bot team and they basically told me "listen for push events which contain both the commit hash and the PR and store that somwhere". which isn't really possible since ofborg has no DB | 20:29:25 |
 emily | 🥴 | 20:29:43 |
| 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 |
