| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When multiple threads try to upsert the same file, this could fail.
Fixes #4667.
|
|
Fixes #4671.
|
|
improve man page for nix.conf (builders)
|
|
|
|
|
|
A few versioning mistakes were corrected:
- In 27b5747ca7b5599768083dde5fa4d36bfbb0f66f, Daemon protocol had some
version `>= 0xc` that should have been `>= 0x1c`, or `28` since the
other conditions used decimal.
- In a2b69660a9b326b95d48bd222993c5225bbd5b5f, legacy SSH gated new CAS
info on version 6, but version 5 in the server. It is now 6
everywhere.
Additionally, legacy ssh was sending over more metadata than the daemon
one was. The daemon now sends that data too.
CC @regnat
Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
|
|
It was in the header but never implemented.
|
|
obsidiansystems/derivation-goal-detect-invalid-output
Throw error for derivation goal with bogus wanted output
|
|
Restore now-working build-remote-content-addressed-fixed test
|
|
Don't let them inherit the signature from the parent one (because it
makes no sense to do so), but re-sign them after they have been built
|
|
Broken atm
|
|
I guess the rationale behind the old name wath that
`pathInfoIsTrusted(info)` returns `true` iff we would need to `blindly`
trust the path (because it has no valid signature and `requireSigs` is
set), but I find it to be a really confusing footgun because it's quite
natural to give it the opposite meaning.
|
|
Not exposed anywhere, but built realisations are now signed (and this
should be forwarded when copy-ing them around)
|
|
Substitute content-addressed derivations
|
|
There were done when StorePath was defined in Rust and there were some
FFI issues. This is no longer an issue.
|
|
|
|
- UsageError -> Error
- include drv path too
|
|
|
|
To prepare for the upcoming DrvOutputSubstitutionGoal
|
|
libstore: support passing a builder's public SSH host key
|
|
|
|
What happened was that Nix was trying to unconditionally mount these
paths in fixed-output derivations, but since the outer derivation was
pure, those paths did not exist. The solution is to only mount those
paths when they exist.
|
|
|
|
|
|
|
|
This separates the scheduling logic (including simple hook pathway) from
the local-store needing code.
This should be the final split for now. I'm reasonably happy with how
it's turning out, even before I'm done moving code into
`local-derivation-goal`. Benefits:
1. This will help "witness" that the hook case is indeed a lot simpler,
and also compensate for the increased complexity that comes from
content-addressed derivation outputs.
2. It also moves us ever so slightly towards a world where we could use
off-the-shelf storage or sandboxing, since `local-derivation-goal`
would be gutted in those cases, but `derivation-goal` should remain
nearly the same.
The new `#if 0` in the new files will be deleted in the following
commit. I keep it here so if it turns out more stuff can be moved over,
it's easy to do so in a way that preserves ordering --- and thus
prevents conflicts.
N.B.
```sh
git diff HEAD^^ --color-moved --find-copies-harder --patience --stat
```
makes nicer output.
|
|
Doing this prior to splitting, so we get better diff with default
options (e.g. on GitHub).
|
|
Build ca derivations remotely
|
|
|
|
|
|
|
|
|
|
The experimental feature was by mistake required for `nix copy` to work
at oll
|
|
Mostly removing useless comments and adding spaces before `&`
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
This should already hold, but better ensure it for future-proof-nees
|
|
Rather throw a proper exception, and catch&log it on the client side
|
|
That way we can copy the realisations too (in addition to the store
paths themselves)
|
|
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.
|
|
This is technically a breaking change, since attempting to set plugin
files after the first non-flag argument will now throw an error. This
is acceptable given the relative lack of stability in a plugin
interface and the need to tie the knot somewhere once plugins can
actually define new subcommands.
|
|
We know the flag will be ignored but the user wants it to take effect.
|
|
Add x86_64 compute levels as system features
|
|
This field used to be a `BasicDerivation`, but this `BasicDerivation`
was downcasted to a `Derivation` when needed (implicitely or not), so we
might as well make it a full `Derivation` and upcast it when needed.
This also allows getting rid of a weird duplication in the way we
compute the static output hashes for the derivation. We had to
do it differently and in a different place depending on whether the
derivation was a full derivation or just a basic drv, but we can now do
it unconditionally on the full derivation.
Fix #4559
|
|
There was already some logic for that, but it didn't handle the case of
content-addressed outputs, so extend it a bit for that
|
|
Otherwise they don't get registered, triggering an assertion failure
at some point later
|
|
To allow it to build ca derivations remotely
|
|
To allow it to build ca derivations remotely
|
|
To allow it to build ca derivations remotely
|
|
- Pass it the name of the outputs rather than their output paths (as
these don't exist for ca derivations)
- Get the built output paths from the remote builder
- Register the new received realisations
|
|
|
