| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This way no derivation has to expect that these files are in the `cwd`
during the build. This is problematic for `nix-shell` where these files
would have to be inserted into the nix-shell's `cwd` which can become
problematic with e.g. recursive `nix-shell`.
To remain backwards-compatible, the location inside the build sandbox
will be kept, however using these files directly should be deprecated
from now on.
|
|
This is needed to push the adoption of structured attrs[1] forward. It's
now checked if a `__json` exists in the environment-map of the derivation
to be openend in a `nix-shell`.
Derivations with structured attributes enabled also make use of a file
named `.attrs.json` containing every environment variable represented as
JSON which is useful for e.g. `exportReferencesGraph`[2]. To
provide an environment similar to the build sandbox, `nix-shell` now
adds a `.attrs.json` to `cwd` (which is mostly equal to the one in the
build sandbox) and removes it using an exit hook when closing the shell.
To avoid leaking internals of the build-process to the `nix-shell`, the
entire logic to generate JSON and shell code for structured attrs was
moved into the `ParsedDerivation` class.
[1] https://nixos.mayflower.consulting/blog/2020/01/20/structured-attrs/
[2] https://nixos.org/manual/nix/unstable/expressions/advanced-attributes.html#advanced-attributes
|
|
In case a previous interrupted build left a garbage path laying around,
remove it before trying to move the path to its final location.
Fix #4858
|
|
|
|
Also add a small architecture to easily run CA-enabled tests
|
|
Fix #4823
|
|
Resolve the derivation before trying to load its environment −
essentially reproducing what the build loop does − so that we can
effectively access our dependencies (and not just their placeholders).
Fix #4821
|
|
Make ca-derivations require a `ca-derivations` machine feature, and
ca-aware builders expose it.
That way, a network of builders can mix ca-aware and non-ca-aware
machines, and the scheduler will send them in the right place.
|
|
When the `keep-going` option is set to `true`, make `nix flake check`
continue as much as it can before failing.
The UI isn’t perfect as-it-is as all the lines currently start with a
mostly useless `error (ignored): error:` prefix, but I’m not sure what
the best output would be, so I’ll leave it as-it-is for the time being
(This is a bit hijacking the `keep-going` flag as it’s supposed to be a
build-time only thing. But I think it’s faire to reuse it here).
Fix https://github.com/NixOS/nix/issues/4450
|
|
When adding a path to the local store (via `LocalStore::addToStore`),
ensure that the `ca` field of the provided `ValidPathInfo` does indeed
correspond to the content of the path.
Otherwise any untrusted user (or any binary cache) can add arbitrary
content-addressed paths to the store (as content-addressed paths don’t
need a signature).
|
|
|
|
Make sure that whenever we substitute a realisation, we also substitute
its entire closure
|
|
|
|
Add a realisations disk cache
|
|
Implement `builtins.floor` and `builtins.ceil` using the C library functions internally
|
|
internally
Closes #4782
Note: even though the type is internally called `NixFloat`, it's
actually a `double`.
|
|
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
|
|
Make sure that their timestamp are always normalized.
Otherwise, strange − and non-deterministic − things might happen, like
https://github.com/NixOS/nixpkgs/issues/121813
Fix #4775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fetchGit: don't prefix "refs/heads/" on ref = "HEAD"
|
|
|
|
Add a CI check to ensure compatibility with an old daemon
|
|
When multiple threads try to upsert the same file, this could fail.
Fixes #4667.
|
|
|
|
First, "XDG_CONFIG_HOME" shouldn't be named "home", as it may be
confusing compared with `$HOME`, which an upcoming test will be using.
Then, using a fixed location for the test is problematic. Use
`$TEST_ROOT` instead.
|
|
Fixes #4613.
|
|
|
|
Doesn't make sense anymore with the new setup
|
|
That way we can run them without rebuilding Nix
|
|
|
|
This requires adding `nix` to its own closure which is a bit unfortunate,
but as it is optional (the test will be disabled if `OUTER_NIX` is unset) it
shouldn't be too much of an issue.
(Ideally this should go in another derivation so that we can build Nix and run
the test independently, but as the tests are running in the same derivation
as the build it's a bit complicated to do so).
|
|
Fixes syntax error introduced in 54ced9072b94515a756e1e8e76c92a42f0ccf366.
|
|
Restore now-working build-remote-content-addressed-fixed test
|
|
Broken atm
|
|
Substitute content-addressed derivations
|
|
|
|
|
|
Requires a slight update to the test infra to work properly, but
having the possibility to group tests that way makes the whole thing
quite cleaner imho
|
|
This was
- Added in dbf96e10ecc75410c9db798f208f8a8310842a4f.
- Commented out in 07975979aae4e7729ae13ffeb7390d07d71ad4bd, which I
believe only reached master by mistake.
- Deleted in c32168c9bc161e0c9cea027853895971699510cb, when
`tests/build-hook-ca.nix` was reused for a new test.
But the test works, and we ought to have it.
|
|
Build ca derivations remotely
|
|
This is probably what most people expect it to do. Fixes #3781.
There is a new command 'nix flake lock' that has the old behaviour of
'nix flake update', i.e. it just adds missing lock file entries unless
overriden using --update-input.
|
|
|
|
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.
|
|
Add x86_64 compute levels as system features
|
