max/nix-super
1
0
Fork 0
mirror of https://github.com/privatevoid-net/nix-super.git synced 2024-11-10 00:08:07 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
nix-super/tests/functional/fixed.sh

72 lines
2.1 KiB
Bash
Raw Normal View History

Ensure all functional scripts are (a) executable (b) have shebang This is good for shebang, and also good for future build system simplifications
2024-05-28 19:43:04 +03:00
#!/usr/bin/env bash
* Tests for fixed-output derivations (and attribute selection, incidentally).
2006-03-01 20:26:21 +02:00
source common.sh
tests/functional: Skip tests that don't work in NixOS environment yet
2024-06-16 13:51:46 +03:00
TODO_NixOS
* Test case to show that parallel builds of different fixed-output derivations that produce the same output path don't work properly wrt locking. This happens a lot in the build farm when fetchurl derivations downloading the same file on different platforms are executed in parallel and then copied back to the main machine.
2007-08-28 12:21:47 +03:00
clearStore
Remove nix-build --hash Instead, if a fixed-output derivation produces has an incorrect output hash, we now unconditionally move the outputs to the path corresponding with the actual hash and register it as valid. Thus, after correcting the hash in the Nix expression (e.g. in a fetchurl call), the fixed-output derivation doesn't have to be built again. It would still be good to have a command for reporting the actual hash of a fixed-output derivation (instead of throwing an error), but "nix-build --hash" didn't do that.
2018-02-03 11:04:29 +02:00
path=$(nix-store -q $(nix-instantiate fixed.nix -A good.0))
echo 'testing bad...'
nix-build fixed.nix -A bad --no-out-link && fail "should fail"
# Building with the bad hash should produce the "good" output path as
# a side-effect.
[[ -e $path ]]
nix path-info --json $path | grep fixed:md5:2qk15sxzzjlnpjk9brn7j8ppcd
* Test case to show that parallel builds of different fixed-output derivations that produce the same output path don't work properly wrt locking. This happens a lot in the build farm when fetchurl derivations downloading the same file on different platforms are executed in parallel and then copied back to the main machine.
2007-08-28 12:21:47 +03:00
echo 'testing good...'
Don't put results symlinks in the tests directory
2012-09-12 02:14:15 +03:00
nix-build fixed.nix -A good --no-out-link
* Tests for fixed-output derivations (and attribute selection, incidentally).
2006-03-01 20:26:21 +02:00
build: also throw hash-mismatch errors if `buildMode == bmCheck` This actually bit me quite recently in `nixpkgs` because I assumed that `nix-build --check` would also error out if hashes don't match anymore[1] and so I wrongly assumed that I couldn't reproduce the mismatch error. The fix is rather simple, during the output registration a so-called `delayedException` is instantiated e.g. if a FOD hash-mismatch occurs. However, in case of `nix-build --check` (or `--rebuild` in case of `nix build`), the code-path where this exception is thrown will never be reached. By adding that check to the if-clause that causes an early exit in case of `bmCheck`, the issue is gone. Also added a (previously failing) test-case to demonstrate the problem. [1] https://github.com/NixOS/nixpkgs/pull/139238, the underlying issue was that `nix-prefetch-git` returns different hashes than `fetchgit` because the latter one fetches submodules by default.
2021-09-26 16:20:36 +03:00
if isDaemonNewer "2.4pre20210927"; then
echo 'testing --check...'
nix-build fixed.nix -A check --check && fail "should fail"
fi
* Test case to show that parallel builds of different fixed-output derivations that produce the same output path don't work properly wrt locking. This happens a lot in the build farm when fetchurl derivations downloading the same file on different platforms are executed in parallel and then copied back to the main machine.
2007-08-28 12:21:47 +03:00
echo 'testing good2...'
Don't put results symlinks in the tests directory
2012-09-12 02:14:15 +03:00
nix-build fixed.nix -A good2 --no-out-link
* Tests for fixed-output derivations (and attribute selection, incidentally).
2006-03-01 20:26:21 +02:00
* Test case to show that parallel builds of different fixed-output derivations that produce the same output path don't work properly wrt locking. This happens a lot in the build farm when fetchurl derivations downloading the same file on different platforms are executed in parallel and then copied back to the main machine.
2007-08-28 12:21:47 +03:00
echo 'testing reallyBad...'
* Refactoring: remove unnecessary variables from the tests.
2011-10-11 00:32:34 +03:00
nix-instantiate fixed.nix -A reallyBad && fail "should fail"
* Tests for fixed-output derivations (and attribute selection, incidentally).
2006-03-01 20:26:21 +02:00
Only test bug fix with new enough deamon
2024-01-08 17:17:28 +02:00
if isDaemonNewer "2.20pre20240108"; then
echo 'testing fixed with references...'
expectStderr 1 nix-build fixed.nix -A badReferences | grepQuiet "not allowed to refer to other store paths"
fi
Improve error message for fixed-outputs with references. This codepath is possible, e.g. with a dockerTools.pullImage of an image with a Nix store.
2023-12-24 13:44:56 +02:00
* Tests for fixed-output derivations (and attribute selection, incidentally).
2006-03-01 20:26:21 +02:00
# While we're at it, check attribute selection a bit more.
* Test case to show that parallel builds of different fixed-output derivations that produce the same output path don't work properly wrt locking. This happens a lot in the build farm when fetchurl derivations downloading the same file on different platforms are executed in parallel and then copied back to the main machine.
2007-08-28 12:21:47 +03:00
echo 'testing attribute selection...'
* Refactoring: remove unnecessary variables from the tests.
2011-10-11 00:32:34 +03:00
test $(nix-instantiate fixed.nix -A good.1 | wc -l) = 1
* Test case to show that parallel builds of different fixed-output derivations that produce the same output path don't work properly wrt locking. This happens a lot in the build farm when fetchurl derivations downloading the same file on different platforms are executed in parallel and then copied back to the main machine.
2007-08-28 12:21:47 +03:00
# Test parallel builds of derivations that produce the same output.
# Only one should run at the same time.
echo 'testing parallelSame...'
clearStore
Don't put results symlinks in the tests directory
2012-09-12 02:14:15 +03:00
nix-build fixed.nix -A parallelSame --no-out-link -j2
* Unify the treatment of sources copied to the store, and recursive SHA-256 outputs of fixed-output derivations. I.e. they now produce the same store path: $ nix-store --add x /nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x $ nix-store --add-fixed --recursive sha256 x /nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x the latter being the same as the path that a derivation derivation { name = "x"; outputHashAlgo = "sha256"; outputHashMode = "recursive"; outputHash = "..."; ... }; produces. This does change the output path for such fixed-output derivations. Fortunately they are quite rare. The most common use is fetchsvn calls with SHA-256 hashes. (There are a handful of those is Nixpkgs, mostly unstable development packages.) * Documented the computation of store paths (in store-api.cc).
2008-12-03 17:06:30 +02:00
# Fixed-output derivations with a recursive SHA-256 hash should
# produce the same path as "nix-store --add".
echo 'testing sameAsAdd...'
Don't put results symlinks in the tests directory
2012-09-12 02:14:15 +03:00
out=$(nix-build fixed.nix -A sameAsAdd --no-out-link)
* Unify the treatment of sources copied to the store, and recursive SHA-256 outputs of fixed-output derivations. I.e. they now produce the same store path: $ nix-store --add x /nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x $ nix-store --add-fixed --recursive sha256 x /nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x the latter being the same as the path that a derivation derivation { name = "x"; outputHashAlgo = "sha256"; outputHashMode = "recursive"; outputHash = "..."; ... }; produces. This does change the output path for such fixed-output derivations. Fortunately they are quite rare. The most common use is fetchsvn calls with SHA-256 hashes. (There are a handful of those is Nixpkgs, mostly unstable development packages.) * Documented the computation of store paths (in store-api.cc).
2008-12-03 17:06:30 +02:00
# This is what fixed.builder2 produces...
rm -rf $TEST_ROOT/fixed
mkdir $TEST_ROOT/fixed
mkdir $TEST_ROOT/fixed/bla
echo "Hello World!" > $TEST_ROOT/fixed/foo
ln -s foo $TEST_ROOT/fixed/bar
* Refactoring: remove unnecessary variables from the tests.
2011-10-11 00:32:34 +03:00
out2=$(nix-store --add $TEST_ROOT/fixed)
Support SHA-512 hashes Fixes #679. Note: on x86_64, SHA-512 is considerably faster than SHA-256 (198 MB/s versus 131 MB/s).
2015-11-04 17:31:06 +02:00
[ "$out" = "$out2" ]
* Unify the treatment of sources copied to the store, and recursive SHA-256 outputs of fixed-output derivations. I.e. they now produce the same store path: $ nix-store --add x /nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x $ nix-store --add-fixed --recursive sha256 x /nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x the latter being the same as the path that a derivation derivation { name = "x"; outputHashAlgo = "sha256"; outputHashMode = "recursive"; outputHash = "..."; ... }; produces. This does change the output path for such fixed-output derivations. Fortunately they are quite rare. The most common use is fetchsvn calls with SHA-256 hashes. (There are a handful of those is Nixpkgs, mostly unstable development packages.) * Documented the computation of store paths (in store-api.cc).
2008-12-03 17:06:30 +02:00
* Refactoring: remove unnecessary variables from the tests.
2011-10-11 00:32:34 +03:00
out3=$(nix-store --add-fixed --recursive sha256 $TEST_ROOT/fixed)
Support SHA-512 hashes Fixes #679. Note: on x86_64, SHA-512 is considerably faster than SHA-256 (198 MB/s versus 131 MB/s).
2015-11-04 17:31:06 +02:00
[ "$out" = "$out3" ]
* Unify the treatment of sources copied to the store, and recursive SHA-256 outputs of fixed-output derivations. I.e. they now produce the same store path: $ nix-store --add x /nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x $ nix-store --add-fixed --recursive sha256 x /nix/store/j2fq9qxvvxgqymvpszhs773ncci45xsj-x the latter being the same as the path that a derivation derivation { name = "x"; outputHashAlgo = "sha256"; outputHashMode = "recursive"; outputHash = "..."; ... }; produces. This does change the output path for such fixed-output derivations. Fortunately they are quite rare. The most common use is fetchsvn calls with SHA-256 hashes. (There are a handful of those is Nixpkgs, mostly unstable development packages.) * Documented the computation of store paths (in store-api.cc).
2008-12-03 17:06:30 +02:00
* Refactoring: remove unnecessary variables from the tests.
2011-10-11 00:32:34 +03:00
out4=$(nix-store --print-fixed-path --recursive sha256 "1ixr6yd3297ciyp9im522dfxpqbkhcw0pylkb2aab915278fqaik" fixed)
Support SHA-512 hashes Fixes #679. Note: on x86_64, SHA-512 is considerably faster than SHA-256 (198 MB/s versus 131 MB/s).
2015-11-04 17:31:06 +02:00
[ "$out" = "$out4" ]
Make `outputHashAlgo` accept `"nar"`, stay in sync Now that we have a few things identifying content address methods by name, we should be consistent about it. Move up the `parseHashAlgoOpt` for tidiness too. Discussed this change for consistency's sake as part of #8876 Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
2024-02-13 22:22:31 +02:00
# Can use `outputHashMode = "nar";` instead of `"recursive"` now.
clearStore
nix-build fixed.nix -A nar-not-recursive --no-out-link
Reference in a new issue Copy permalink