-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Checking broken with only some outputs #13293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Comments
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this issue
May 29, 2025
We move the `assertPathValidity` to where we know what the wanted outputs are.
Merged
#13294 This implements solution (3) above. |
xokdvium
pushed a commit
to xokdvium/nix
that referenced
this issue
May 29, 2025
We move the `assertPathValidity` to where we know what the wanted outputs are.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this issue
Jun 11, 2025
It currently fails, before the fix.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this issue
Jun 11, 2025
We move the `assertPathValidity` to where we know what the wanted outputs are.
Ericson2314
added a commit
to obsidiansystems/nix
that referenced
this issue
Jun 11, 2025
We move the `assertPathValidity` to where we know what the wanted outputs are.
Ericson2314
added a commit
that referenced
this issue
Jun 11, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
Since
DerivationBuildingGoal
was split out (3b617e4), checking is broken because of anDerivationBuildingGoal::assertPathValidity
call atnix/src/libstore/unix/build/derivation-builder.cc
Line 2854 in 3b617e4
The issue is that
DerivationBuildingGoal
doesn't know what outputs are wanted any more. This was intentional --- when we are building rather than substituting, we know we are going to produce all outputs. However thisassertPathValidity
was happening before the build, and was intended to check that the outputs we want to repair are all there.Steps To Reproduce
Expected behavior
It should be fine to only repair some outputs, just like before
Metadata
Bisected to 3b617e4
Additional context
I would like to not solve this issue by reintroducing
wantedOutputs
toDerivationBuildingGoal
. Can we instead solve this problem a different way?Possible solutions:
DerivationGoal
after we return do the check. Then we're back to knowing what output we want.Checklist
Add 👍 to issues you find important.
CC @xokdvium
The text was updated successfully, but these errors were encountered: