 | NixOS Infrastructure | 374 Members |
| Next Infra call: 2024-07-11, 18:00 CEST (UTC+2) | Infra operational issues backlog: https://github.com/orgs/NixOS/projects/52 | See #infra-alerts:nixos.org for real time alerts from Prometheus. | 114 Servers |
| NixOS Infrastructure | 374 Members |
| Next Infra call: 2024-07-11, 18:00 CEST (UTC+2) | Infra operational issues backlog: https://github.com/orgs/NixOS/projects/52 | See #infra-alerts:nixos.org for real time alerts from Prometheus. | 114 Servers |
| Sender | Message | Time |
|---|---|---|
| 26 Dec 2025 | ||
 gabyx | * yes, I mean also on aarch which I dont have but not sure... | 15:09:44 |
 Janne | Sorry, I can't really find it rn. But essentially you take every commit message, split on :, run nix-build -A on the first part of the split | 15:13:37 |
| Janne | This is not correct BTW. The macs are paid for by the foundation | 15:14:46 |
| gabyx | Wouldn't also be helpful, if one could have some yaml annotation in the PR decscriptionwhich 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...) | 15:15:00 |
| gabyx | * Wouldn't also be helpful, if one could have some yaml annotation in the PR decscriptionwhich 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 (optional) etc. like ofBorg does but in Github Actions (note: I hate Github Actions to the core..., the worst...) | 15:15:42 |
| gabyx | * Wouldn't also be helpful, if one could have some yaml annotation in the PR decscriptionwhich 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:02 |
 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 decscriptionwhich 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.orgI 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 |