| Age | Commit message (Collapse) | Author |
|---|
|
Based off on @dtzWill's #2276
|
|
|
|
Make sure that we can’t build the same derivation twice at the same
time.
Fix https://github.com/NixOS/nix/issues/5029
|
|
Fill `NIX_CONFIG` with the value of the current Nix configuration before
calling the nix subprocesses in the repl
That way the whole configuration (including the possible
`experimental-features`, a possibly `--store` option or whatever) will
be made available.
This is required for example to make `nix repl` work with a custom
`--store`
|
|
Make the CA tests actually test something
|
|
Add an access-control list to the realisations in recursive-nix (similar
to the already existing one for store paths), so that we can build
content-addressed derivations in the restricted store.
Fix #4353
|
|
Fix #4837
|
|
Gracefully handle duplicate realisations
|
|
Make `nix-shell` support content-addressed derivations
|
|
|
|
Make `computeFSClosure` ca-aware
|
|
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
|
|
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
|
|
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).
|
|
|
|
|
|
|
|
Doesn't make sense anymore with the new setup
|
|
|
|
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
|
|
|
|
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
|
|
|
|
|
|
When performing distributed builds of machine learning packages, it
would be nice if builders without the required SIMD instructions can
be excluded as build nodes.
Since x86_64 has accumulated a large number of different instruction
set extensions, listing all possible extensions would be unwieldy.
AMD, Intel, Red Hat, and SUSE have recently defined four different
microarchitecture levels that are now part of the x86-64 psABI
supplement and will be used in glibc 2.33:
https://gitlab.com/x86-psABIs/x86-64-ABI
https://lwn.net/Articles/844831/
This change uses libcpuid to detect CPU features and then uses them to
add the supported x86_64 levels to the additional system types. For
example on a Ryzen 3700X:
$ ~/aps/bin/nix -vv --version | grep "Additional system"
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
|
|
Just a few small things needed fixing!
|
|
|
|
remove-storetype-delegate-regStore
|
|
Doesn't test much, but at least ensures that the command runs properly
|
|
|
|
|
|
|
|
|
|
|
|
This seems more correct. It also means one can specify the features a
store should support with --store and remote-store=..., which is useful.
I use this to clean up the build remotes test.
|
|
|
|
|
|
|
|
Reuse the pre-existing list rather than the one written as part of #3777
|
|
|
|
The previous regex was too strict and did not match what git was allowing. It
could lead to `fetchGit` not accepting valid branch names, even though they
exist in a repository (for example, branch names containing `/`, which are
pretty standard, like `release/1.0` branches).
The new regex defines what a branch name should **NOT** contain. It takes the
definitions from `refs.c` in https://github.com/git/git and `git help
check-ref-format` pages.
This change also introduces a test for ref name validity checking, which
compares the result from Nix with the result of `git check-ref-format --branch`.
|
|
(cherry picked from commit f459ca547fda4b0ca477d895413e86b69a580ab0)
|
|
|
|
|
