| 26 Dec 2025 |
 leona | i don't think we should use github actions even more. And probably GitHub will have a problem with doing that at scale | 15:16:15 |
 gabyx | * Stupid question: Wouldn't also be helpful, if one could have some yaml annotation in the PR decscription
which could be taken up in a Github job which could then do some special attribute builds (you need just git commit --amend && git push )?
Just a simple stupid Nix VM (Github Job) which builds the requested attribute on requested arch ...
like ofBorg does but in Github Actions (note: I hate Github Actions to the core..., the worst...) | 15:16:18 |
| gabyx | is there any plan there? | 15:17:27 |
| leona | I don't know of any | 15:17:43 |
 Janne | Probably waiting for them to cancel us | 15:17:54 |
| gabyx | cause of too many actions? | 15:18:07 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @gabyx:matrix.org
Wouldn't also be helpful, if one could have some yaml annotation in the PR decscription
which could be taken up in a Github job which could then do some special attribute builds?
Just a simple stupid Nix VM (Github Job) which builds the requested attribute on requested arch (optional) etc.
like ofBorg does but in Github Actions (note: I hate Github Actions to the core..., the worst...) I wonder if github allows you to register some bots to do it yourself, just like the shitty copilot review | 15:18:29 |
| gabyx | the only thing I see with github action VMs is they start pretty fast... | 15:19:01 |
| Janne | Ofborg actually receives most things that happen in nixpkgs from a webhook, one could subscribe to that rabbitmq queue | 15:19:12 |
| gabyx | * the only thing I see with github action VMs is they start pretty fast... and for OSS there is not limit | 15:19:15 |
| gabyx | * the only thing I see with github action VMs is they start pretty fast... and for OSS there is not limit AFAIK | 15:19:20 |
| gabyx | ofborg runs as single binary on a few VMs with different arch? | 15:20:40 |
 emily | fwiw if we get Enterprise then we will have more Actions minutes than we know what to do with | 15:20:55 |
| emily | although the runners are really just incredibly slow | 15:21:01 |
| Janne | It's a surprising amount of components. But one is the webhook receiver which receives webhook events and streams them to a queue. Multiple subscribers can hook to that | 15:21:27 |
| emily | (I think ofborg is more maintainer-time-limited than theoretical-ability-to-get-builder-CPU-limited though) | 15:21:48 |
| Janne | It absolutely is. That's why we thought about merging relevant functionality into the queue runner to reduce the amount of duplicate work | 15:22:20 |
| gabyx | ah and the subscribers are then actually running on the VMs with different archs... | 15:22:28 |
| Janne | Mostly, yes | 15:22:42 |
| gabyx | Nice. | 15:22:53 |
| Janne | There is a graph here: https://pad.lassul.us/ofborg-sustainability?both#Look-around-coreofborgorg | 15:23:12 |
| emily | tbh I expect it would probably be possible to simplify ofborg's architecture significantly by driving it through GHA (while still running builds elsewhere). but of course that is a lot of work that nobody wants to do… (and lock-in is certainly a thing, although ofborg is not particularly load-bearing there compared to other things tied to GHA currently) | 15:26:46 |
| 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 (signing key rotation when) | A propos ofborg | 15:47:55 |
| hexa (signing key rotation when) | @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 (signing key rotation when) | maybe we could also kill x86_64-darwin early and prioritize aarch64-darwin | 15:49:13 |
