| Age | Commit message (Collapse) | Author |
|---|
|
Using virtual inheritance means that only the default constructors of
the parent classes will be called, which isn't what we want
|
|
Rework the `Store` hierarchy so that there's now one hierarchy for the
store configs and one for the implementations (where each implementation
extends the corresponding config). So a class hierarchy like
```
StoreConfig-------->Store
| |
v v
SubStoreConfig----->SubStore
| |
v v
SubSubStoreConfig-->SubSubStore
```
(with virtual inheritance to prevent DDD).
The advantage of this architecture is that we can now introspect the configuration of a store without having to instantiate the store itself
|
|
|
|
Don't let it just contain the value, but also the other fields of the
setting (description, aliases, etc..)
|
|
Add a new `init()` method to the `Store` class that is supposed to
handle all the effectful initialisation needed to set-up the store.
The constructor should remain side-effect free and just initialize the
c++ data structure.
The goal behind that is that we can create “dummy” instances of each
store to query static properties about it (the parameters it accepts for
example)
|
|
|
|
Directly register the store classes rather than a function to build an
instance of them.
This gives the possibility to introspect static members of the class or
choose different ways of instantiating them.
|
|
We no longer need the `*Opt` to disambiguate.
|
|
|
|
Otherwise, we will associate fixed-output derivations with outputs that
they did indeed produce, but which had the wrong hash. That's no good.
|
|
|
|
remove-storetype-delegate-regStore
|
|
Add a fallback path in `queryPartialDerivationOutputMap` for daemons
that don't support it.
Also upstreams a couple methods from `SSHStore` to `RemoteStore` as this
is needed to handle the fallback path.
|
|
Fixes #3992.
|
|
When deploying a Hydra instance with current Nix master, most builds
would not run because of errors like this:
queue monitor: error: --- Error --- hydra-queue-runner
error: --- UsageError --- nix-daemon
not a content address because it is not in the form '<prefix>:<rest>': /nix/store/...-somedrv
The last error message is from parseContentAddress, which expects a
colon-separated string, however what we got here is a store path.
Looking at the worker protocol, the following message sent to the Nix
daemon caused the error above:
0x1E -> wopQuerySubstitutablePathInfos
0x01 -> Number of paths
0x16 -> Length of string
"/nix/store/...-somedrv"
0x00 -> Length of string
""
Looking at writeStorePathCAMap, the store path is indeed the first field
that's transmitted. However, readStorePathCAMap expects it to be the
*second* field *on my machine*, since expression evaluation order is a
classic form of unspecified behaviour[1] in C++.
This has been introduced in https://github.com/NixOS/nix/pull/3689,
specifically in commit 66a62b3189c8c9b0965850e6b3c9b0fda0b50fd8.
[1]: https://en.wikipedia.org/wiki/Unspecified_behavior#Order_of_evaluation_of_subexpressions
Signed-off-by: aszlig <aszlig@nix.build>
|
|
If we resolve using the known path of a derivation whose output we
didn't have, we previously blew up. Now we just fail gracefully,
returning the map of all outputs unknown.
|
|
ca-floating-upstream
|
|
- More and better comments
- The easier renames
|
|
Thanks!
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>
|
|
We will sometimes try to query the outputs of derivations we can't
resolve. That's fine; it just means we don't know what those outputs are
yet.
|
|
ca-floating-upstream
|
|
|
|
|
|
|
|
This means profiles outside of /nix/var/nix/profiles don't get
garbage-collected. It also means we don't need to scan
/nix/var/nix/profiles for GC roots anymore, except for compatibility
with previously existing generations.
|
|
|
|
|
|
|
|
|
|
ca-floating-upstream
|
|
Thanks for catching, @regnat.
|
|
ca-floating-upstream
|
|
|
|
Revise division of labor in deserialization of derivations
|
|
As pointed out by @B4dM4n, the call to to.flush() on stderrThread is
unsafe because the NAR writer thread is also writing to 'to'.
Fixes #3943.
|
|
|
|
Co-authored-by: Théophane Hufschmitt <regnat@users.noreply.github.com>
|
|
|
|
|
|
DummyStore does not allow building or adding paths. This is useful for
evaluation tests when you don't want to initialize a "proper" store.
|
|
tabs -> spaces
|
|
|
|
|
|
Insead they should be opaque `/<hash>` like the placeholders we already
have.
|
|
Sorry I let the tab sneak in there in the first place.
|
|
|
|
|
|
- `queryDerivationOutputMapAssumeTotal` -> `queryPartialDerivationOutputMap`
- `queryDerivationOutputMapAssumeTotal` -> `queryDerivationOutputMap
|
|
`queryDerivationOutputMap` no longer assumes all outputs have a mapping
|
