| 16 Jun 2026 |
Vladimír Čunát | (out of ~160k) | 06:51:12 |
hexa | 7580 of which are nixos tests, where half are duplicated with the allDrivers attribute | 11:07:59 |
hexa | https://github.com/NixOS/nixpkgs/pull/176099 | 11:09:21 |
hexa | do we really need to build that? | 11:09:58 |
hexa | Robert Hensing (roberth)? | 11:10:10 |
Robert Hensing (roberth) | the allDrivers set has all the configs, testScript, etc, but is already part of nixosTests proper. They don't add extra build work, but may add extra eval work given that multiple batches of evaluation are needed for the tests, and it seems unlikely that the allDrivers vs tests run in the same batch (unless someone has added a workaround specifically for this - I assume the batches are cut lexicographically) | 11:13:41 |
Robert Hensing (roberth) | tl;dr they're eval work not extra build work | 11:13:54 |
hexa | they can be extra build work, if the builds land on different hosts. and they contribute to the overall job count changes quite a bit. | 11:14:26 |
leona | but they cause stress for the queue runner, as they are actual queue jobs, no? | 11:14:40 |
Robert Hensing (roberth) | what? the builders don't share a cache?? | 11:14:42 |
hexa | they ultimately do, but it takes time to push things to it | 11:15:07 |
hexa | timeouts that we get from aws s3 excacerbate the situation | 11:15:28 |
Robert Hensing (roberth) | :( | 11:15:36 |
Robert Hensing (roberth) | I wouldn't mind if allDrivers were removed or dontRecurseIntoAttrs, unless tfc makes regular use of it? | 11:16:51 |
tfc | the alldrivers attribute is important. it exposes if/when there are problems with changes to the driver module system, linter settings etc. | 11:39:10 |
K900 | Except we still build all the actual tests/ | 11:39:33 |
K900 | * Except we still build all the actual tests? | 11:39:34 |
K900 | So we still build the exact same derivations | 11:39:41 |
K900 | Again | 11:39:44 |
tfc | i see that this is annoying from the CI perspective. from a maintainer perspective i build the alldriver symbol at home for my and other people's PRs. | 11:40:30 |
leona | is it important that it gets build by hydra? I mean we can still provide it in Nixpkgs | 11:40:48 |
tfc | it would be a bit of a shame if we couldn't have that because CI (re)builds them unnecessarily | 11:40:53 |
leona | * is it important that it gets built by hydra? I mean we can still provide it in Nixpkgs | 11:40:55 |
tfc | not important that hydra builds it | 11:40:59 |
leona | that's my suggestion for that https://github.com/NixOS/nixpkgs/pull/532396 | 18:16:35 |
leona | even makes GHA eval ~1.89% faster ^^ | 18:17:15 |
| 18 Jun 2026 |
r-burns | python3.pkgs.fakeredis fails some tests on staging-next-26.05, bumping to latest seems to fix it. Bump doesn't seem to cause breakage on master so potentially could merge to master -> backport 26.05 -> merge into staging-next-26.05 if that seems cleaner than a cherry-pick. | 00:40:45 |
hexa | master -> release-26.05 sounds fine to me | 00:42:19 |
hexa | probably another fallout from the valkey 9.1 update that surely had no breaking changes | 00:42:57 |
hexa | Redacted or Malformed Event | 00:43:05 |