| 29 Dec 2024 |
 @janne.hess:helsinki-systems.de | 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.hess:helsinki-systems.de | 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.hess:helsinki-systems.de | Sounds like an interesting idea, yeah | 20:30:26 |
| @janne.hess:helsinki-systems.de | 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.hess:helsinki-systems.de |
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.hess:helsinki-systems.de | 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.hess:helsinki-systems.de | Yep, one of the pain points :D | 20:32:50 |
| @janne.hess:helsinki-systems.de | 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.hess:helsinki-systems.de | Yes unfortunately | 20:33:17 |
| @janne.hess:helsinki-systems.de | 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.hess:helsinki-systems.de | 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.hess:helsinki-systems.de | 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 |
