| Age | Commit message (Collapse) | Author |
|---|
|
Whereas `ContentAddressWithReferences` is a sum type complex because different
varieties support different notions of reference, and
`ContentAddressMethod` is a nested enum to support that,
`ContentAddress` can be a simple pair of a method and hash.
`ContentAddress` does not need to be a sum type on the outside because
the choice of method doesn't effect what type of hashes we can use.
Co-Authored-By: Cale Gibbard <cgibbard@gmail.com>
|
|
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
|
|
This reverts commit ee9eb83a842eb97d0180fd9d349d30ff27fdb485.
|
|
With the switch to C++20, the rules became more strict, and we can no
longer initialize base classes. Make them comments instead.
(BTW
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2287r1.html
this offers some new syntax for this use-case. Hopefully this will be
adopted and we can eventually use it.)
|
|
|
|
Proposal: Use C++20
|
|
We don't need it yet, we can add it back later.
|
|
This change can wait for another PR.
|
|
|
|
Ca/fix nix log
|
|
- `PathReferences` -> `References`
- `PathReferences<StorePath>` -> `StoreReference`
- `references` -> `others`
- `hasSelfReference` -> `self`
And get rid of silly subclassing
|
|
|
|
|
|
|
|
Fix #6209
When trying to run `nix log <installable>`, try first to resolve the derivation pointed to
by `<installable>` as it is the resolved one that holds the build log.
This has a couple of shortcomings:
1. It’s expensive as it requires re-reading the derivation
2. It’s brittle because if the derivation doesn’t exist anymore or can’t
be resolved (which is the case if any one of its build inputs is missing),
then we can’t access the log anymore
However, I don’t think we can do better (at least not right now).
The alternatives I see are:
1. Copy the build log for the un-resolved derivation. But that means a
lot of duplication
2. Store the results of the resolving in the db. Which might be the best
long-term solution, but leads to a whole new class of potential
issues.
|
|
|
|
|
|
|
|
|
|
|
|
Also use std::string_view in a few more places.
|
|
|
|
|
|
|
|
|
|
These were needed back in the pre-C++11 era because we didn't have
move semantics. But now we do.
|
|
async realisation substitution
|
|
Allow references in addPath
|
|
Co-Authored-By: Eelco Dolstra <edolstra@gmail.com>
|
|
Since 4806f2f6b0fd2cae401b89fe19d8c528ffd88b5f, we can't have paths with
references passed to builtins.{path,filterSource}. This prevents many cases
of those functions called on IFD outputs from working. Resolve this by
passing the references found in the original path to the added path.
|
|
That way we can fetch several realisations from the same cache in
parallel
|
|
Doesn’t change much so far because everything is still using it
synchronously, but should allow the binary cache to fetch stuff in
parallel
|
|
Allow to pass a set of references to be added as info to the added paths.
|
|
This fixes a bug in the garbage collector where if a path
/nix/store/abcd-foo is valid, but we do a
isValidPath("/nix/store/abcd-foo.lock") first, then a negative entry
for /nix/store/abcd is added to pathInfoCache, so /nix/store/abcd-foo
is subsequently considered invalid and deleted.
|
|
Based off on @dtzWill's #2276
|
|
|
|
|
|
Signed-off-by: Pamplemousse <xav.maso@gmail.com>
|
|
I never remember the exact syntax of the `switch` statement
|
|
Similar to the nar-info disk cache (and using the same db).
This makes rebuilds muuch faster.
- This works regardless of the ca-derivations experimental feature.
I could modify the logic to not touch the db if the flag isn’t there,
but given that this is a trash-able local cache, it doesn’t seem to be
really worth it.
- We could unify the `NARs` and `Realisation` tables to only have one
generic kv table. This is left as an exercise to the reader.
- I didn’t update the cache db version number as the new schema just
adds a new table to the previous one, so the db will be transparently
migrated and is backwards-compatible.
Fix #4746
|
|
|
|
|
|
the compressed hash"
|
|
compressed hash
This change is to simplify [Trustix](https://github.com/tweag/trustix) indexing and makes it possible to reconstruct this URL regardless of the compression used.
In particular this means that https://github.com/tweag/trustix/blob/7c2e9ca597de233846e0b265fb081626ca6c59d8/contrib/nix/nar/nar.go#L61-L71 can be removed and only the bits that are required to establish trust needs to be published in the Trustix build logs.
|
|
Was crashing because coercing a json document into a string is only
valid if the json is a string, otherwise we need to call `.dump()`
|
|
Because of a too eager refactoring, `addTextToStore` used to throw an
error because the input wasn't a valid nar.
Partially revert that refactoring to wrap the text into a proper nar
(using `dumpString`) to make this method work again
|
|
Fix #4332
|
|
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.
|
