| 26 Dec 2025 |
 Janne | Maybe that GHA thing fixes itself if too many people get too annoyed by the 504s. This is why we are going to mirror all relevant repos because more often that not people are unable to work | 15:28:02 |
 gabyx | indeed quite complex with some good amount of queues =). Would love to contribute to more Rust stuff, if you have anything reasonably boring/simple-> you may ping me, I may/could help).
emily : I think nobody wants to invest time into the rabbit holes of GHA... its just crap and there is IMO no hope into the future they are going to improve that, until proven otherwise: the latest about this mayhem which is sooo ooold...
| 15:30:28 |
| Janne | I will try to remember that, thank you for that offer :) | 15:31:02 |
 dish [Fox/It/She] | In reply to @emilazy:matrix.org
although the runners are really just incredibly slow has there been any thought put into seeing if we could use another actions provider(blacksmith, deploy, etc) to provide faster runners for some subset of jobs? I imagine several of those providers have FOSS project plans that the NixOS org could possibly take advantage of | 15:33:26 |
 hexa | A propos ofborg | 15:47:55 |
| hexa | @janne:hess.ooo we have to m1 minis in transit that we could allocate to ofborg | 15:48:14 |
| gabyx | IMO: Also to consider is the following when switching to a new CI:
- You actually would like to drive the whole Pipeline by code (ideally typed) not YAML.
Several methods to achieve that, certain providers are able to do dynamic pipelines (which might take slight overhead, dep. on how fast the jobs are and the pipeline generation).
This gives some much better observability/maintainability in the long term etc. (In our projects we only do that, with Gitlab and only Nix, and with Go)
Maybe even simplesr for nixpkgs, a tool which just generates a bunch of derivations to build which are the CI jobs, (could be anything, linting, testing, formatting etc... )?
| 15:48:50 |
| hexa | maybe we could also kill x86_64-darwin early and prioritize aarch64-darwin | 15:49:13 |
 emily | we could also just self-host runners | 15:49:22 |
| emily | but those are going to have an additional charge at some point 🙃 | 15:49:32 |
| hexa | * @janne:hess.ooo we have two m1 minis in transit that we could allocate to ofborg | 15:49:41 |
|  jappie @ 39c3 changed their display name from jappie to jappie @ 39c3. | 15:49:41 |
| emily | IIRC ofborg x86_64-darwin capacity is actual Intel Macs, right? | 15:49:58 |
| hexa | * | 15:50:02 |
| hexa | Mixed I think, but I might be mis remembering | 15:50:19 |
| emily | so nominally they're not taking away any compute from aarch64-darwin (but I agree it makes sense to not prioritize any further work there) | 15:50:22 |
| gabyx | self-host runners -> is still the shitty GHA, the question is more does nixpkgs want to stay on that system? | 15:50:34 |
| gabyx | * self-host runners -> is still the shitty GHA, the question is more does nixpkgs want to stay on that system? On that runner which runs with node and has all sorts of flaws like overwritting the $HOME env var in every container etc etc if you need containers ... | 15:51:24 |
| dish [Fox/It/She] | is there a better option for the needs of nixpkgs atm? there's been a very large push to use GHA for the moment, plus github is providing a lot of free compute we aren't getting if we move to another splution | 15:52:44 |
| dish [Fox/It/She] | of course theres always a better option, but considering the limitations and benefits of using GHA at the moment... 🤷♀️ | 15:53:16 |
| dish [Fox/It/She] | just my thoughts to be clear, not trying to speak for anyone else | 15:56:51 |
| emily | GHA is already load-bearing for many more things than ofborg | 16:10:13 |
| emily | we already have migration pain there if we wanted to stop using it, might as well benefit from it | 16:10:43 |
| Janne | That would be great | 16:19:33 |
|  aktaboot changed their profile picture. | 19:25:55 |
 mynacol | For non-foundation use you can always just throw https://github.com/Defelo/nixpkgs-review-gha at a PR and also run nixos tests, just like with local nixpkgs-review. If individuals use it, this should be very much fine for Github, but is not feasible for running automatically on PRs by the NixOS org (except they get enterprise plan sponsored, I hear). | 22:32:33 |
| gabyx | ah nice: but not sure I quite understand that tool, this repo is a GHA setup which runs nixpkgs-review.
So you can trigger this repo's action (how?) and it will pull the PR, and build the attribute on all platforms? | 22:38:36 |
| mynacol | Read the readme :). It explains how you can run it. And just try it.
I found it a month ago and think it's ingenious. | 22:43:32 |
| gabyx | Jeah I probably got the answer. | 22:43:52 |
| gabyx | Its certainly good, also ingenious would be: a local tool which runs on qemu VMs, such that you dont need to debug stupid GHA yaml etc... | 22:50:11 |
