| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This avoids an ambiguity where the `StorePathWithOutputs { drvPath, {}
}` could mean "build `brvPath`" or "substitute `drvPath`" depending on
context.
It also brings the internals closer in line to the new CLI, by
generalizing the `Buildable` type is used there and makes that
distinction already.
In doing so, relegate `StorePathWithOutputs` to being a type just for
backwards compatibility (CLI and RPC).
|
|
libstore: support passing a builder's public SSH host key
|
|
This is already used by Hydra, and is very useful when materializing
a remote builder list from service discovery. This allows the service
discovery tool to only sync one file instead of two.
|
|
To allow it to build ca derivations remotely
|
|
We embrace virtual the rest of the way, and get rid of the
`assert(false)` 0-param constructors.
We also list config base classes first, so the constructor order is
always:
1. all the configs
2. all the stores
Each in the same order
|
|
For each known realisation, store:
- its output
- its output path
This comes with a set of needed changes:
- New `realisations` module declaring the types needed for describing
these mappings
- New `Store::registerDrvOutput` method registering all the needed informations
about a derivation output (also replaces `LocalStore::linkDeriverToPath`)
- new `Store::queryRealisation` method to retrieve the informations for a
derivations
This introcudes some redundancy on the remote-store side between
`wopQueryDerivationOutputMap` and `wopQueryRealisation`.
However we might need to keep both (regardless of backwards compat)
because we sometimes need to get some infos for all the outputs of a
derivation (where `wopQueryDerivationOutputMap` is handy), but all the
stores can't implement it − because listing all the outputs of a
derivation isn't really possible for binary caches where the server
doesn't allow to list a directory.
|
|
This was useful for an experiment with building Nix as a single
compilation unit. It's not very useful otherwise but also doesn't
hurt...
|
|
|
|
This reverts commit 9ab07e99f527d1fa3adfa02839da477a1528d64b.
|
|
|
|
This gets rid of the inclusion of <future> in util.hh, cutting
compilation time by ~20s (CPU time).
Issue #4045.
|
|
Work around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80431 that was
already there in the code but was accidentally removed in the last
commits
|
|
So that it can be printed by `nix describe-stores`
|
|
|
|
When opening a store, only try the stores whose `uriSchemes()` include
the current one
|
|
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
|
|
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.
|
|
|
|
Define `LegacySSHStore::buildPaths` using `cmdBuildPaths`
|
|
Evidentally this was never implemented because Nix switched to using
`buildDerivation` exclusively before `build-remote.pl` was rewritten.
The `nix-copy-ssh` test (already) tests this.
|
|
|
|
github.com:obsidiansystems/nix into templated-daemon-protocol
|
|
|
|
We did this in the same spirit of the dummy value that's present in
libstore/path.hh
|
|
|
|
templated-daemon-protocol
|
|
This refactor should *not* change the wire protocol.
|
|
better-ca-parse-errors
|
|
|
|
This is only used by hydra-queue-runner and it's better to implement
it there.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
|
|
|
|
|
|
|
|
|
|
This does a few enums; the rest will be gotten in subsequent commits.
|
|
Most functions now take a StorePath argument rather than a Path (which
is just an alias for std::string). The StorePath constructor ensures
that the path is syntactically correct (i.e. it looks like
<store-dir>/<base32-hash>-<name>). Similarly, functions like
buildPaths() now take a StorePathWithOutputs, rather than abusing Path
by adding a '!<outputs>' suffix.
Note that the StorePath type is implemented in Rust. This involves
some hackery to allow Rust values to be used directly in C++, via a
helper type whose destructor calls the Rust type's drop()
function. The main issue is the dynamic nature of C++ move semantics:
after we have moved a Rust value, we should not call the drop function
on the original value. So when we move a value, we set the original
value to bitwise zero, and the destructor only calls drop() if the
value is not bitwise zero. This should be sufficient for most types.
Also lots of minor cleanups to the C++ API to make it more modern
(e.g. using std::optional and std::string_view in some places).
|
|
|
|
This is to assert that callback functions should never throw (since
the context in which they're called may not be able to handle the
exception).
|
|
|
