feat: use a reworked generic nixos test for wrappers extension
#1743
Conversation
yvan-sraka
force-pushed
the
multi-version-ext/wrappers
branch
from
39652f5 to
0087bd8
Compare
yvan-sraka
changed the title
wrappers extension
yvan-sraka
force-pushed
the
multi-version-ext/wrappers
branch
from
0087bd8 to
cab79ee
Compare
yvan-sraka
changed the title
wrappers extensionwrappers extension
.github/workflows/nix-build.yml
Outdated
| nix run "github:Mic92/nix-fast-build?rev=b1dae483ab7d4139a6297e02b6de9e5d30e43d48" | ||
| -- --skip-cached --no-nom ${{ matrix.runner == 'macos-latest-xlarge' && '--max-jobs 1' || '' }} | ||
| --flake ".#checks.$(nix eval --raw --impure --expr 'builtins.currentSystem')" | ||
| - run: nix build -L '.#${{ matrix.attr }}' |
There was a problem hiding this comment.
@yvan-sraka sorry if I missed the discussion somewhere, in this approach do we move nix-fast-build to some other level, or do we just not need it any more
There was a problem hiding this comment.
We use nix-fast-build when we run nix develop (as it's nice to quickly have a working developer environment). However, in CI, it's better, IMHO, to have jobs run sequentially, particularly when you want to reproduce an issue in CI (if your build fails in multiple places, it's impractical to assert that you fixed one issue if they occur out of order). WDYT?
There was a problem hiding this comment.
But it's indeed different if the runner is not ephemeral and has some persistent /nix/store. In that case, nix-fast-build has some value since it avoids some redownloading (it partially caches even failed builds). It might make sense to reintroduce it when we have the new runners :)
This is a follow-up of #1637 and #1663