ci/eval: fail on asserts when generating attrpaths#426629
ci/eval: fail on asserts when generating attrpaths#426629wolfgangwalther merged 3 commits intoNixOS:masterfrom
Conversation
da3ad86 to
d388542
Compare
|
Amazing work. I merged the pieces that I think are completely uncontroversial. |
d388542 to
2b49c26
Compare
This comment was marked as resolved.
This comment was marked as resolved.
cc4e9e8 to
dde5e03
Compare
philiptaron
left a comment
There was a problem hiding this comment.
I don't love AAAAAASomeThingsFailToEvaluate but it's fine.
dde5e03 to
88f2a41
Compare
|
Rebased to trigger CI once more and confirm that no other breakage has been introduced on master. Given that there have been no objections other than keeping the The related issue still needs more work as pointed out above, but this will ensure that this first part doesn't regress. |
88f2a41 to
88329b1
Compare
|
Not merging because of a regression in #427219 (comment). Edit: Will wait for the channel to be unblocked in case there are any other eval errors hiding that require a revert of the linux commit. |
This is already not used in-tree, so should be a variant.
This removes pkgsx86_64Darwin from the top-level attributes when generating attrpaths for evaluation on Linux. Needed for attrpaths generation to succeed without silently catching eval errors. Variants are still available during actual Eval for references from other packages, just not during attrpath generation. To remove it from Eval as well, issues around pkgsLLVM will have to be fixed first.
This doesn't fail on *all* asserts, yet, because nix-env still ignores these in the main eval step. But it already gives some converage during the attrpath generation.
88329b1 to
30f19cc
Compare
Is this resolved now with #428023 merged?
Is there an unrelated channel blocker that's preventing us from knowing if this PR is good now? |
Correct.
I don't know of any other channel blocker, no. But it could be that hydra spits out another Eval error, at least in theory. That's because the one above was not noticed because of #426629 (comment) - aka the outpath-step silently catching those errors. TLDR:
This PR in itself is not a problem and could be merged. It's just the case of: What if we get another eval error from one of the earlier changes, that we can't easily fix - and thus we want to revert, for example, the "remove the assert in the linux kernel" commit? Once we revert that, we must revert this, too. Thus, I'd rather wait a bit here to make sure that all the previous changes made it through hydra once. |
Ah, I see. That makes sense. It is also possible that a new regression will show up on master after the changes that we're waiting to see go through hydra but before the point at which we eventually merge this PR. However that seems unlikely, so I agree it's better to wait. |
|
Release checks, which previously failed, are good now: https://hydra.nixos.org/job/nixpkgs/trunk/unstable#tabs-constituents The only two pending jobs (manual, metrics) I see there have passed before, so if they fail it's unrelated to us. |
|
Successfully created backport PR for |
Work towards #397184.
TLDR of that issue: In the attrpaths generation step for Eval, we catch and ignore evaluation errors here:
nixpkgs/pkgs/top-level/release-attrpaths-superset.nix
Lines 99 to 107 in ab88976
We do this because a lot of asserts/throws are used to give feedback about invalid combinations of things for the current system, throw errors for non-accepted licenses etc. But that also means we silently ignore asserts/throws where they point at a real problem, for example when
mkDerivationtriggers an assert.We can show these eval failures by turning on
enableWarningsforrelease-attrpaths-superset.nix. This will give us:This PR fixes only the warnings for x86_64-linux, and then disables theit would be good to get rid of all the warnings, though... ✅tryEvallogic only on that platform. Arguably this gives us a lot already, because most attributes are evaluated on x86_64-linux, too, and most real eval failures will surface this way. Eventually,We need to do the following things first:
throws about removals are just made aliases, which they should have been anyway. various: move throws to aliases #426639meta.brokenfor some lua packages, instead of rolling their owndisabled+throw. lua{54,Jit}Packages.lua-pam: mark as broken #426640flutterPackages.betawhich tries to calllib.laston an empty list. flutterPackages.beta: fix eval #426641config.allowAliasesas mentioned in Eval check not catching certain eval errors #397184 (comment). various: avoid throwing for invalid platforms combinations in CI #426645In here we also do:
pkgsx86_64Darwin, which doesn't eval on Linux.Things done
ci -A eval.attrpathsSuperseton platform:Add a 👍 reaction to pull requests you find important.