| 29 Dec 2024 |
 emily | (and did the "do actual builds on GHA" plan die?) | 20:26:02 |
 Janne Heß | I honestly don't know myself tbh | 20:26:19 |
| emily | fair enough :) | 20:26:31 |
| Janne Heß | I'm trying to preserve as much as I can from the current way it is (but dropping some GHA-replaced things like the rebuild counters). It's currently in a rough condition but it somewhat works. We still need to eval because the GH API is the absolute worst (at least until someone came up with a better solution) | 20:27:11 |
| emily | GHA eval is faster than ofborg ever was to a shocking degree (to the point where I wonder how ofborg eval latency ever managed to get bad) | 20:27:22 |
| Janne Heß | Don't worry, I stole that code to be able to get cheaper machines ;) | 20:27:43 |
| Janne Heß | evals with ~13-14GB of RAM now | 20:28:00 |
| emily | yay | 20:28:08 |
| emily |
We still need to eval because the GH API is the absolute worst
as in it's hard to get the eval output from the GHA checks?
| 20:28:12 |
| 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 |
