nordic-dev.net/nix
nordic-dev.net/nix
2
0
Fork 0
mirror of https://github.com/NixOS/nix.git synced 2024-11-22 06:42:28 +00:00
Code Issues Packages Projects Releases Wiki Activity
3db75b0060
nix/tests/functional/local.mk

147 lines
3.1 KiB
Makefile
Raw Normal View History

Add support for ‘make installcheck’
2013-11-25 17:47:03 +00:00
nix_tests = \
Harden tests' bash Use `set -u` and `set -o pipefail` to catch accidental mistakes and failures more strongly. - `set -u` catches the use of undefined variables - `set -o pipefail` catches failures (like `set -e`) earlier in the pipeline. This makes the tests a bit more robust. It is nice to read code not worrying about these spurious success paths (via uncaught) errors undermining the tests. Indeed, I caught some bugs doing this. There are a few tests where we run a command that should fail, and then search its output to make sure the failure message is one that we expect. Before, since the `grep` was the last command in the pipeline the exit code of those failing programs was silently ignored. Now with `set -o pipefail` it won't be, and we have to do something so the expected failure doesn't accidentally fail the test. To do that we use `expect` and a new `expectStderr` to check for the exact failing exit code. See the comments on each for why. `grep -q` is replaced with `grepQuiet`, see the comments on that function for why. `grep -v` when we just want the exit code is replaced with `grepInverse, see the comments on that function for why. `grep -q -v` together is, surprise surprise, replaced with `grepQuietInverse`, which is both combined. Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-12-09 15:26:46 +00:00
test-infra.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
gc.sh \
Split out `nix-collect-garbage -d` test to new file Good for test parallelism, and separation of concerns (core GC vs profiles deleting).
2023-05-16 15:25:45 +00:00
nix-collect-garbage-d.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
remote-store.sh \
Add `Store::isTrustedClient()` This function returns true or false depending on whether the Nix client is trusted or not. Mostly relevant when speaking to a remote store with a daemon. We include this information in `nix ping store` and `nix doctor` Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems>
2022-12-26 20:21:08 +00:00
legacy-ssh-store.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
lang.sh \
Fix #11141 broken sp corrector
2024-07-22 12:48:18 +00:00
lang-gc.sh \
Factor out a bit more language testings infra Will be used in a second test after `lang.sh`.
2024-06-23 19:33:45 +00:00
characterisation-test-infra.sh \
Write test, will fail until rest of PR
2023-01-17 00:10:18 +00:00
experimental-features.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
fetchMercurial.sh \
Add a test for auto-GC This currently fails because we're using POSIX file locks. So when the garbage collector opens and closes its own temproots file, it causes the lock to be released and then deleted by another GC instance.
2019-08-02 15:07:33 +00:00
gc-auto.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
user-envs.sh \
Test the migration of the user profiles
2022-04-13 08:26:50 +00:00
user-envs-migration.sh \
Test nix-build with non-local-store --store Just a few small things needed fixing!
2020-12-20 19:55:21 +00:00
binary-cache.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
multiple-outputs.sh \
nix-build.sh \
gc-concurrent.sh \
repair.sh \
fixed.sh \
export-graph.sh \
timeout.sh \
fetchGitRefs.sh \
gc-runtime.sh \
tarball.sh \
fetchGit.sh \
fetchurl.sh \
Implement simple test for `path`-fetcher setting a correct `lastModifiedDate` Co-authored-by: Théophane Hufschmitt <7226587+thufschmitt@users.noreply.github.com>
2022-03-15 11:55:32 +00:00
fetchPath.sh \
fetchTree: Allow fetching plain files Add a new `file` fetcher type, which will fetch a plain file over http(s), or from the local file. Because plain `http(s)://` or `file://` urls can already correspond to `tarball` inputs (if the path ends-up with a know archive extension), the URL parsing logic is a bit convuluted in that: - {http,https,file}:// urls will be interpreted as either a tarball or a file input, depending on the extensions of the path part (so `https://foo.com/bar` will be a `file` input and `https://foo.com/bar.tar.gz` as a `tarball` input) - `file+{something}://` urls will be interpreted as `file` urls (with the `file+` part removed) - `tarball+{something}://` urls will be interpreted as `tarball` urls (with the `tarball+` part removed) Fix #3785 Co-Authored-By: Tony Olagbaiye <me@fron.io>
2020-10-15 23:35:24 +00:00
fetchTree-file.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
simple.sh \
referrers.sh \
optimise-store.sh \
Check the CA hash when importing stuff in the local store 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).
2021-05-27 11:25:25 +00:00
substitute-with-invalid-ca.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
signing.sh \
Split `hash.sh` test in two Converting hashes and hashing files are pretty separate tasks, and more test parallelism is better.
2024-02-13 14:37:45 +00:00
hash-convert.sh \
hash-path.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
gc-non-blocking.sh \
check.sh \
nix-shell.sh \
check-refs.sh \
Merge remote-tracking branch 'upstream/master' into trustless-remote-builder-simple
2020-08-14 16:05:27 +00:00
build-remote-input-addressed.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
secure-drv-outputs.sh \
restricted.sh \
fetchGitSubmodules.sh \
fetchGit and flake: add commit signature verification tests This adds simple tests of the commit signature verification mechanism of fetchGit and its flake input wrapper. OpenSSH is added to the build dependencies since it's needed to create a key when testing the functionality. It is neither a built- nor a runtime dependency.
2023-10-20 19:18:01 +00:00
fetchGitVerification.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
readfile-context.sh \
nix-channel.sh \
recursive.sh \
dependencies.sh \
check-reqs.sh \
Restore now-working build-remote-content-addressed-fixed test 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.
2021-02-26 16:29:19 +00:00
build-remote-content-addressed-fixed.sh \
Test the remote building of ca derivations
2021-01-26 09:28:00 +00:00
build-remote-content-addressed-floating.sh \
Reenable previously failing trustless remote builder tests
2021-02-27 05:33:47 +00:00
build-remote-trustless-should-pass-0.sh \
Trustless remote building Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
2020-08-12 03:47:36 +00:00
build-remote-trustless-should-pass-1.sh \
build-remote-trustless-should-pass-2.sh \
Reenable previously failing trustless remote builder tests
2021-02-27 05:33:47 +00:00
build-remote-trustless-should-pass-3.sh \
Trustless remote building Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
2020-08-12 03:47:36 +00:00
build-remote-trustless-should-fail-0.sh \
mounted-ssh-ng store: integration tests
2023-08-29 16:01:09 +00:00
build-remote-with-mounted-ssh-ng.sh \
Rename tests/nar-index -> tests/nar-access
2017-11-14 12:27:40 +00:00
nar-access.sh \
Functional Test for `builtins.storeDir` and `builtins.currentSystem` These were under-tested. This tests the status quo and especially previous commit of this PR better.
2023-12-15 00:47:10 +00:00
impure-eval.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
pure-eval.sh \
add tests for nix eval and nix-instantiate
2022-03-16 18:57:18 +00:00
eval.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
repl.sh \
binary-cache-build-remote.sh \
search.sh \
logging.sh \
export.sh \
config.sh \
add.sh \
Rename local-store.sh -> chroot-store.sh
2024-03-29 11:51:14 +00:00
chroot-store.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
filter-source.sh \
misc.sh \
dump-db.sh \
linux-sandbox.sh \
Add some tests for `drop-supplementary-groups`
2023-05-15 21:41:51 +00:00
supplementary-groups.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
build-dry.sh \
Add fetchMercurial primop E.g. $ nix eval '(fetchMercurial https://www.mercurial-scm.org/repo/hello)' { branch = "default"; outPath = "/nix/store/alvb9y1kfz42bjishqmyy3pphnrh1pfa-source"; rev = "82e55d328c8ca4ee16520036c0aaace03a5beb65"; revCount = 1; shortRev = "82e55d328c8c"; } $ nix eval '(fetchMercurial { url = https://www.mercurial-scm.org/repo/hello; rev = "0a04b987be5ae354b710cefeba0e2d9de7ad41a9"; })' { branch = "default"; outPath = "/nix/store/alvb9y1kfz42bjishqmyy3pphnrh1pfa-source"; rev = "0a04b987be5ae354b710cefeba0e2d9de7ad41a9"; revCount = 0; shortRev = "0a04b987be5a"; } $ nix eval '(fetchMercurial /tmp/unclean-hg-tree)' { branch = "default"; outPath = "/nix/store/cm750cdw1x8wfpm3jq7mz09r30l9r024-source"; rev = "0000000000000000000000000000000000000000"; revCount = 0; shortRev = "000000000000"; }
2017-11-01 15:32:53 +00:00
structured-attrs.sh \
rename run to shell in tests
2020-04-29 21:37:21 +00:00
shell.sh \
Add pure evaluation mode In this mode, the following restrictions apply: * The builtins currentTime, currentSystem and storePath throw an error. * $NIX_PATH and -I are ignored. * fetchGit and fetchMercurial require a revision hash. * fetchurl and fetchTarball require a sha256 attribute. * No file system access is allowed outside of the paths returned by fetch{Git,Mercurial,url,Tarball}. Thus 'nix build -f ./foo.nix' is not allowed. Thus, the evaluation result is completely reproducible from the command line arguments. E.g. nix build --pure-eval '( let nix = fetchGit { url = https://github.com/NixOS/nixpkgs.git; rev = "9c927de4b179a6dd210dd88d34bda8af4b575680"; }; nixpkgs = fetchGit { url = https://github.com/NixOS/nixpkgs.git; ref = "release-17.09"; rev = "66b4de79e3841530e6d9c6baf98702aa1f7124e4"; }; in (import (nix + "/release.nix") { inherit nix nixpkgs; }).build.x86_64-linux )' The goal is to enable completely reproducible and traceable evaluation. For example, a NixOS configuration could be fully described by a single Git commit hash. 'nixos-rebuild' would do something like nix build --pure-eval '( (import (fetchGit { url = file:///my-nixos-config; rev = "..."; })).system ') where the Git repository /my-nixos-config would use further fetchGit calls or Git externals to fetch Nixpkgs and whatever other dependencies it has. Either way, the commit hash would uniquely identify the NixOS configuration and allow it to reproduced.
2018-01-16 17:50:38 +00:00
brotli.sh \
add tests for zstd compression
2021-04-09 21:13:08 +00:00
zstd.sh \
Add compression level for NARs Based off on @dtzWill's #2276
2021-10-12 06:14:36 +00:00
compression-levels.sh \
Add basic flake tests
2019-05-07 21:22:47 +00:00
nix-copy-ssh.sh \
Test the parallel copy over ssh-ng Regression test for https://github.com/NixOS/nix/issues/6253
2023-08-07 09:23:19 +00:00
nix-copy-ssh-ng.sh \
Merge remote-tracking branch 'origin/master' into flakes
2019-08-08 13:49:13 +00:00
post-hook.sh \
Merge remote-tracking branch 'origin/master' into flakes
2019-08-29 14:11:38 +00:00
function-trace.sh \
nix-fmt: add command
2022-03-11 13:57:28 +00:00
fmt.sh \
Add test for readFile keeping context
2017-11-10 22:51:34 +00:00
eval-store.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
why-depends.sh \
Create `nix derivation add` command Also refine `nix derivation show`'s docs very slightly.
2023-02-17 23:37:35 +00:00
derivation-json.sh \
Functional test for derivation "advanced attrs" This tests the Nix language side of things. We are purposely skipping most of `common.sh` because it is overkill for this test: we don't want to have an "overfit" test environment. Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems>
2024-06-08 11:10:51 +00:00
derivation-advanced-attributes.sh \
Rename import-derivation -> import-from-derivation
2024-09-17 14:55:44 +00:00
import-from-derivation.sh \
Don’t require `NIX_PATH` entries to be valid paths It’s totally valid to have entries in `NIX_PATH` that aren’t valid paths (they can even be arbitrary urls or `channel:<channel-name>`). Fix #5998 and #5980
2022-01-27 14:32:14 +00:00
nix_path.sh \
Add test case for NARs with duplicate directory entries This test was made by @puckipedia.
2024-09-05 14:41:15 +00:00
nars.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
placeholders.sh \
ssh-relay.sh \
Add x86_64 compute levels as additional system types 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
2021-02-16 13:32:12 +00:00
build.sh \
Test `nix build --json` return output paths in floating CA case Adding a test to ensure there is no regression. The tests that are split out of `tests/build.sh` are ones that don't yet work with CA derivation. I have not yet evaluated whether they should or not. This behavior, reported missing in issue #4661, already got fixed in PR #4818, but didn't get a test case then.
2021-03-01 00:15:05 +00:00
build-delete.sh \
output-normalization.sh \
Introduce notion of a test group, use for CA tests Grouping our tests should make it easier to understand the intent than one long poorly-arranged list. It also is convenient for running just the tests for a specific component when working on that component. We need at least one test group so this isn't dead code; I decided to collect the tests for the `ca-derivations` and `dynamic-derivations` experimental features in groups. Do ```bash make ca.test-group -jN ``` and ```bash make dyn-drv.test-group -jN ``` to try running just them. I originally did this as part of #8397 for being able to just the local overlay store alone. I am PRing it separately now so we can separate general infra from new features. Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-07-10 02:24:51 +00:00
selfref-gc.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
db-migration.sh \
tests: Rename nix-profile.sh -> bash-profile.sh
2022-03-02 10:14:31 +00:00
bash-profile.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 13:15:27 +00:00
pass-as-file.sh \
Add some end-to-end tests for the suggestions
2022-03-04 09:29:48 +00:00
nix-profile.sh \
suggestions.sh \
store info sh renamed
2023-10-17 18:42:10 +00:00
store-info.sh \
Add support for impure derivations Impure derivations are derivations that can produce a different result every time they're built. Example: stdenv.mkDerivation { name = "impure"; __impure = true; # marks this derivation as impure outputHashAlgo = "sha256"; outputHashMode = "recursive"; buildCommand = "date > $out"; }; Some important characteristics: * This requires the 'impure-derivations' experimental feature. * Impure derivations are not "cached". Thus, running "nix-build" on the example above multiple times will cause a rebuild every time. * They are implemented similar to CA derivations, i.e. the output is moved to a content-addressed path in the store. The difference is that we don't register a realisation in the Nix database. * Pure derivations are not allowed to depend on impure derivations. In the future fixed-output derivations will be allowed to depend on impure derivations, thus forming an "impurity barrier" in the dependency graph. * When sandboxing is enabled, impure derivations can access the network in the same way as fixed-output derivations. In relaxed sandboxing mode, they can access the local filesystem.
2022-03-30 14:31:01 +00:00
fetchClosure.sh \
Fix the name of the completions test
2022-07-12 07:19:05 +00:00
completions.sh \
Add command 'nix store path-from-hash-part' This exposes the Store::queryPathFromHashPart() interface in the CLI.
2022-10-18 14:42:06 +00:00
impure-derivations.sh \
Trivial changes from the lazy-trees branch
2022-12-07 11:58:58 +00:00
path-from-hash-part.sh \
Make `nix path-info --json` return an object not array Before it returned a list of JSON objects with store object information, including the path in each object. Now, it maps the paths to JSON objects with the metadata sans path. This matches how `nix derivation show` works. Quite hillariously, none of our existing functional tests caught this change to `path-info --json` though they did use it. So just new functional tests need to be added.
2023-10-23 01:12:54 +00:00
path-info.sh \
Support opening local store with database on read-only filesystem (#8356) Previously it was not possible to open a local store when its database is on a read-only filesystem. Obviously a store on a read-only filesystem cannot be modified, but it would still be useful to be able to query it. This change adds a new read-only setting to LocalStore. When set to true, Nix will skip operations that fail when the database is on a read-only filesystem (acquiring big-lock, schema migration, etc), and the store database will be opened in immutable mode. Co-authored-by: Ben Radford <benradf@users.noreply.github.com> Co-authored-by: cidkidnix <cidkidnix@protonmail.com> Co-authored-by: Dylan Green <67574902+cidkidnix@users.noreply.github.com> Co-authored-by: John Ericson <git@JohnEricson.me> Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-06-20 09:34:09 +00:00
toString-path.sh \
Test nested sandboxing, and make nicer error We were bedeviled by sandboxing issues when working on the layered store. The problem ended up being that when we have nested nix builds, and the inner store is inside the build dir (e.g. store is `/build/nix-test/$name/store`, build dir is `/build`) bind mounts clobber each other and store paths cannot be found. After thoroughly cleaning up `local-derivation-goal.cc`, we might be able to make that work. But that is a lot of work. For now, we just fail earlier with a proper error message. Finally, test this: nested sandboxing without the problematic store dir should work, and with should fail with the expected error message. Co-authored-by: Dylan Green <67574902+cidkidnix@users.noreply.github.com> Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2023-07-13 17:17:17 +00:00
read-only-store.sh \
Allow CLI to pass environment variables to FOD builder (#8830) Add a new experimental `impure-env` setting that is a key-value list of environment variables to inject into FOD derivations that specify the corresponding `impureEnvVars`. This allows clients to make use of this feature (without having to change the environment of the daemon itself) and might eventually deprecate the current behaviour (pick whatever is in the environment of the daemon) as it's more principled and might prevent information leakage.
2023-10-11 11:58:42 +00:00
nested-sandboxing.sh \
fix debugger crashing while printing envs fixes #9932
2024-02-04 15:42:00 +00:00
impure-env.sh \
add tests for showing help
2024-03-04 15:07:03 +00:00
debugger.sh \
libstore: check additionalSandboxProfile Make sure that `extraSandboxProfile` is set before we check whether it's empty or not (in the `sandbox=true` case). Also adds a test case for this. Co-Authored-By: Artemis Tosini <lix@artem.ist> Co-Authored-By: Eelco Dolstra <edolstra@gmail.com>
2024-05-06 13:10:18 +00:00
extra-sandbox-profile.sh \
Add support for ‘make installcheck’
2013-11-25 17:47:03 +00:00
Make libcpuid dependency optional with --disable-cpuid
2021-11-27 23:48:04 +00:00
ifeq ($(HAVE_LIBCPUID), 1)
Make indentation in makesfiles consistent Tab (as required) for rules, two spaces for `if`...`endif`.
2024-01-11 01:26:02 +00:00
nix_tests += compute-levels.sh
Make libcpuid dependency optional with --disable-cpuid
2021-11-27 23:48:04 +00:00
endif
Add support for ‘make installcheck’
2013-11-25 17:47:03 +00:00
Use positive source filtering for the standalone functional tests job Additionally this skipping of the building is reimplemented to be a bit more robust and use the same idioms as the functionality for skipping the tests. In particular, it will now work even if the source files exist, so we can do this during development too.
2023-10-06 15:57:31 +00:00
ifeq ($(ENABLE_BUILD), yes)
Make indentation in makesfiles consistent Tab (as required) for rules, two spaces for `if`...`endif`.
2024-01-11 01:26:02 +00:00
nix_tests += test-libstoreconsumer.sh
Don't run the tests that require building if we're not building A couple of tests require building some libraries that depend on Nix, and assume it to be built locally. Don't run these if we only want to run the install tests. This prevents the CI from rebuilding several times Nix (like in https://github.com/NixOS/nix/actions/runs/6404422275/job/17384964033#step:6:6412), thus removing a fair amount of build time.
2023-10-04 15:10:54 +00:00
Make indentation in makesfiles consistent Tab (as required) for rules, two spaces for `if`...`endif`.
2024-01-11 01:26:02 +00:00
ifeq ($(BUILD_SHARED_LIBS), 1)
nix_tests += plugins.sh
endif
Don't run the tests that require building if we're not building A couple of tests require building some libraries that depend on Nix, and assume it to be built locally. Don't run these if we only want to run the install tests. This prevents the CI from rebuilding several times Nix (like in https://github.com/NixOS/nix/actions/runs/6404422275/job/17384964033#step:6:6412), thus removing a fair amount of build time.
2023-10-04 15:10:54 +00:00
endif
nix/tests: run test help.sh only if nix is built with documentation tests/functional/help.sh calls nix-* commands with option --help if nix is built without documentation the option --help throws an error because the man page it wants to display is missing
2024-10-18 09:06:41 +00:00
ifeq ($(ENABLE_DOC_GEN), yes)
nix_tests += help.sh
endif
Put functional tests in `tests/functional` I think it is bad for these reasons when `tests/` contains a mix of functional and integration tests - Concepts is harder to understand, the documentation makes a good unit vs functional vs integration distinction, but when the integration tests are just two subdirs within `tests/` this is not clear. - Source filtering in the `flake.nix` is more complex. We need to filter out some of the dirs from `tests/`, rather than simply pick the dirs we want and take all of them. This is a good sign the structure of what we are trying to do is not matching the structure of the files. With this change we have a clean: ```shell-session $ git show 'HEAD:tests' tree HEAD:tests functional/ installer/ nixos/ ```
2023-10-05 16:12:18 +00:00
$(d)/test-libstoreconsumer.sh.test $(d)/test-libstoreconsumer.sh.test-debug: \
Use `buildprefix` in a few more places `installcheck` doesn't yet work, but the rest of the build can now happen mostly inside a separate build directory. Progress on #9342 Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-11-25 05:33:21 +00:00
$(buildprefix)$(d)/test-libstoreconsumer/test-libstoreconsumer
Put functional tests in `tests/functional` I think it is bad for these reasons when `tests/` contains a mix of functional and integration tests - Concepts is harder to understand, the documentation makes a good unit vs functional vs integration distinction, but when the integration tests are just two subdirs within `tests/` this is not clear. - Source filtering in the `flake.nix` is more complex. We need to filter out some of the dirs from `tests/`, rather than simply pick the dirs we want and take all of them. This is a good sign the structure of what we are trying to do is not matching the structure of the files. With this change we have a clean: ```shell-session $ git show 'HEAD:tests' tree HEAD:tests functional/ installer/ nixos/ ```
2023-10-05 16:12:18 +00:00
$(d)/plugins.sh.test $(d)/plugins.sh.test-debug: \
Use `buildprefix` in a few more places `installcheck` doesn't yet work, but the rest of the build can now happen mostly inside a separate build directory. Progress on #9342 Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-11-25 05:33:21 +00:00
$(buildprefix)$(d)/plugins/libplugintest.$(SO_EXT)
Don't run the tests that require building if we're not building A couple of tests require building some libraries that depend on Nix, and assume it to be built locally. Don't run these if we only want to run the install tests. This prevents the CI from rebuilding several times Nix (like in https://github.com/NixOS/nix/actions/runs/6404422275/job/17384964033#step:6:6412), thus removing a fair amount of build time.
2023-10-04 15:10:54 +00:00
Make `tests/dyn-drv` test dir
2023-04-19 22:49:50 +00:00
install-tests += $(foreach x, $(nix_tests), $(d)/$(x))
Add support for ‘make installcheck’
2013-11-25 17:47:03 +00:00
Put functional tests in `tests/functional` I think it is bad for these reasons when `tests/` contains a mix of functional and integration tests - Concepts is harder to understand, the documentation makes a good unit vs functional vs integration distinction, but when the integration tests are just two subdirs within `tests/` this is not clear. - Source filtering in the `flake.nix` is more complex. We need to filter out some of the dirs from `tests/`, rather than simply pick the dirs we want and take all of them. This is a good sign the structure of what we are trying to do is not matching the structure of the files. With this change we have a clean: ```shell-session $ git show 'HEAD:tests' tree HEAD:tests functional/ installer/ nixos/ ```
2023-10-05 16:12:18 +00:00
test-clean-files := \
Shellcheck some test scripts Progress on #10795
2024-05-28 14:10:02 +00:00
$(d)/common/subst-vars.sh \
Introduce notion of a test group, use for CA tests Grouping our tests should make it easier to understand the intent than one long poorly-arranged list. It also is convenient for running just the tests for a specific component when working on that component. We need at least one test group so this isn't dead code; I decided to collect the tests for the `ca-derivations` and `dynamic-derivations` experimental features in groups. Do ```bash make ca.test-group -jN ``` and ```bash make dyn-drv.test-group -jN ``` to try running just them. I originally did this as part of #8397 for being able to just the local overlay store alone. I am PRing it separately now so we can separate general infra from new features. Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-07-10 02:24:51 +00:00
$(d)/config.nix
Add support for ‘make installcheck’
2013-11-25 17:47:03 +00:00
Put functional tests in `tests/functional` I think it is bad for these reasons when `tests/` contains a mix of functional and integration tests - Concepts is harder to understand, the documentation makes a good unit vs functional vs integration distinction, but when the integration tests are just two subdirs within `tests/` this is not clear. - Source filtering in the `flake.nix` is more complex. We need to filter out some of the dirs from `tests/`, rather than simply pick the dirs we want and take all of them. This is a good sign the structure of what we are trying to do is not matching the structure of the files. With this change we have a clean: ```shell-session $ git show 'HEAD:tests' tree HEAD:tests functional/ installer/ nixos/ ```
2023-10-05 16:12:18 +00:00
clean-files += $(test-clean-files)
test-deps += $(test-clean-files)
Reference in New Issue Copy Permalink