| 16 May 2026 |
 vcunat | Maybe the new queue-runner will change that significantly. No idea, maybe I'm just too optimistic.
| 13:44:12 |
| vcunat | * Maybe the new queue-runner will change the price significantly. No idea, maybe I'm just too optimistic.
| 13:44:20 |
 emily | I'd guess it's a lot of raw CPU time for the actual tests too? 🤔 | 13:46:31 |
| emily | I'll try to at least work on the "no separate NixOS and Nixpkgs jobset" thing after branch off, which might alleviate the "duplicate scheduling or build work between the two" problem... maybe we can cut out non-blocking tests for now at the same time | 13:48:08 |
| vcunat | The raw CPU time is minority here. I'm quite sure. | 13:51:36 |
| vcunat | It's mainly building loads of tiny .drv (for /etc), loads of cheap huge .drv (disk-image whatever), etc. Moving them there and back, compressing, to S3. Lots of delays which you will not notice when running a NixOS test locally. | 13:53:02 |
| emily | right | 13:53:20 |
| vcunat | At least that's what it looks like from my years-long observation of what Hydra is doing. | 13:53:23 |
| emily | ...the disk images probably aren't great for cache growth either though :) | 13:53:36 |
| vcunat | With a good GC strategy that might not be a problem (in future). | 13:53:58 |
| vcunat | * With a good GC strategy for S3 that might not be a problem (in future). | 13:54:09 |
| emily | yeah.... mostly I'm just sceptical that non-blocking tests get much consumption from Hydra anyway. package bumps, spot-checking if functionality is working, people including them in their configs for bonus assurance - Hydra building them is pretty extraneous | 13:57:01 |
| emily | the main case I can imagine them providing value is notification when they break. but uh, haven't seen much evidence that any maintainer is proactively checking when their stuff breaks, so probably a bigger deal to establish that norm for packages first. and anyone going to the trouble of setting up a notification system can probably spare the cycles to build the test | 13:58:16 |
| vcunat | A nice way to follow failures for particular jobs (packages/tests) would be a useful improvement, though that's tangential here. | 14:02:06 |
| emily | yeah, I agree. I'm very much in favour of better notifications and delegating work to maintainers | 14:04:50 |
| emily | but I'm guessing that even adding "every test anyone active is interested in following" back in would be relatively little 😅 | 14:05:12 |
| emily | I mean, it would be really nice if we could cut staging-nixos out of the process again. | 14:06:00 |
| vcunat | Oh right, I didn't realize that implication. | 14:24:31 |
