module-eval: say how to read the verdict without a build
The check's results are already embedded in its builder text — the comment
above `runCommand` says so — but nothing said that this makes the verdict
readable straight out of the derivation. So mutation-testing a case, which
is the documented way to prove a case can fail, has been costing a build on
the shared farm per arm when it costs none.
Command verified against both arms: on an unmutated tree it prints the
`N properties hold` line, and with a case deliberately broken it prints that
case's `FAILED:` line. The jq shape is envelope-agnostic, since `derivation
show` grew a `{"derivations": …}` wrapper.
This commit is contained in:
parent
978e66790c
commit
c90b999285
1 changed files with 7 additions and 0 deletions
|
|
@ -571,6 +571,13 @@ in
|
||||||
# The results are embedded in the builder text on purpose: that is what
|
# The results are embedded in the builder text on purpose: that is what
|
||||||
# makes this derivation's hash depend on them, so a nix-only change that
|
# makes this derivation's hash depend on them, so a nix-only change that
|
||||||
# flips a case cannot be answered from cache.
|
# flips a case cannot be answered from cache.
|
||||||
|
#
|
||||||
|
# It also means the verdict can be read without building anything, which is
|
||||||
|
# what makes mutation-testing a case affordable — mutate, re-read, restore,
|
||||||
|
# with nothing queued on the shared builder:
|
||||||
|
#
|
||||||
|
# nix derivation show .#checks.<system>.module-eval \
|
||||||
|
# | jq -r '..|.buildCommand? // empty'
|
||||||
pkgs.runCommand "hyperhive-module-eval" { } ''
|
pkgs.runCommand "hyperhive-module-eval" { } ''
|
||||||
${report}
|
${report}
|
||||||
${
|
${
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue