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

152 lines
3.2 KiB
Makefile
Raw Normal View History

Add support for ‘make installcheck’
2013-11-25 19:47:03 +02: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 17:26:46 +02:00
test-infra.sh \
Make init.sh safe to run twice `init.sh` is tested on its own. We used to do that. I deleted it in 4720853129b6866775edd9f90ad6f10701f98a3c but I am not sure why. Better to just restore it; at one point working on this every other test passed, so seems good to check whether `init.sh` can be run twice. We don't *need* to run `init.sh` twice, but I want to try to make our tests as robust as possible so that manual debugging (where tests for better or worse might be run ways that we didn't expect) is less fragile.
2021-12-09 17:16:18 +02:00
init.sh \
Move flakes tests to a subdirectory
2022-07-13 15:09:35 +03:00
flakes/flakes.sh \
flakes/run.sh \
Split off the Mercurial flake tests
2022-07-13 15:40:39 +03:00
flakes/mercurial.sh \
Split off the circular flake import tests
2022-07-13 21:16:39 +03:00
flakes/circular.sh \
Split off 'nix flake init' tests
2022-07-13 21:36:11 +03:00
flakes/init.sh \
flakes: Ensure that `self.outPath == ./.` Users expect `self` to refer to the directory where the `flake.nix` file resides.
2023-02-09 23:10:30 +02:00
flakes/inputs.sh \
Split off following paths tests
2022-07-13 21:46:22 +03:00
flakes/follow-paths.sh \
Move the 'nix bundle' tests Note: these were previously not actually called.
2022-07-13 21:49:07 +03:00
flakes/bundle.sh \
Split off 'nix flake check' tests
2022-07-13 22:01:16 +03:00
flakes/check.sh \
Trivial changes from the lazy-trees branch
2022-12-07 13:58:58 +02:00
flakes/unlocked-override.sh \
flakes/absolute-paths.sh \
test: test behavior of .-prefixed attrPaths
2023-08-27 11:42:52 +03:00
flakes/absolute-attr-paths.sh \
InstallableFlake::toDerivedPaths(): Support paths and store paths This makes 'nix build' work on paths (which will be copied to the store) and store paths (returned as is). E.g. the following flake output attributes can be built using 'nix build .#foo': foo = ./src; foo = self.outPath; foo = builtins.fetchTarball { ... }; foo = (builtins.fetchTree { .. }).outPath; foo = builtins.fetchTree { .. } + "/README.md"; foo = builtins.storePath /nix/store/...; Note that this is potentially risky, e.g. foo = /.; will cause Nix to try to copy the entire file system to the store. What doesn't work yet: foo = self; foo = builtins.fetchTree { .. }; because we don't handle attrsets with an outPath attribute in it yet, and foo = builtins.storePath /nix/store/.../README.md; since result symlinks have to point to a store path currently (rather than a file inside a store path). Fixes #7417.
2022-12-16 00:01:15 +02:00
flakes/build-paths.sh \
Add a test with flake.nix in a submodule I noticed a regression in the lazy-trees branch, which I'm trying to capture with this test. While the tests succeeds in master, the lazy-trees branch gives the following error message: error: access to path '/build/nix-test/tests/flakes/flake-in-submodule/rootRepo/submodule/flake.nix' is forbidden because it is not under Git control; maybe you should 'git add' it to the repository '/build/nix-test/tests/flakes/flake-in-submodule/rootRepo'?
2023-03-17 22:10:55 +02:00
flakes/flake-in-submodule.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 15:15:27 +02: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 18:25:45 +03: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 15:15:27 +02: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 22:21:08 +02: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 15:15:27 +02:00
lang.sh \
Expanded test suite * Lang now verifies errors and parse output * Some new miscellaneous tests * Easy way to update the tests * Document workflow in manual * Use `!` not `~` as separater char for sed It is confusing to use `~` when we are talking about paths and home directories! * Test test suite itself (`test/lang-test/infra.sh`) Additionally, run shellcheck on `tests/lang.sh` to help ensure it is correct, now that is is more complex. Co-authored-by: Robert Hensing <roberth@users.noreply.github.com> Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2015-09-04 23:23:08 +03:00
lang-test-infra.sh \
Write test, will fail until rest of PR
2023-01-17 02:10:18 +02: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 15:15:27 +02: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 18:07:33 +03: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 15:15:27 +02:00
user-envs.sh \
Test the migration of the user profiles
2022-04-13 11:26:50 +03:00
user-envs-migration.sh \
Test nix-build with non-local-store --store Just a few small things needed fixing!
2020-12-20 21:55:21 +02: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 15:15:27 +02: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 13:55:32 +02: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-16 02:35:24 +03: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 15:15:27 +02: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 14:25:25 +03: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 15:15:27 +02:00
signing.sh \
hash.sh \
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 19:05:27 +03: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 15:15:27 +02:00
secure-drv-outputs.sh \
restricted.sh \
fetchGitSubmodules.sh \
Move flake-searching.sh and make it less dependent on git
2022-07-13 21:55:08 +03:00
flakes/search-root.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 15:15:27 +02: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 18:29:19 +02:00
build-remote-content-addressed-fixed.sh \
Test the remote building of ca derivations
2021-01-26 11:28:00 +02:00
build-remote-content-addressed-floating.sh \
Reenable previously failing trustless remote builder tests
2021-02-27 07:33:47 +02:00
build-remote-trustless-should-pass-0.sh \
Trustless remote building Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
2020-08-12 06:47:36 +03: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 07:33:47 +02:00
build-remote-trustless-should-pass-3.sh \
Trustless remote building Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
2020-08-12 06:47:36 +03:00
build-remote-trustless-should-fail-0.sh \
Rename tests/nar-index -> tests/nar-access
2017-11-14 14:27:40 +02:00
nar-access.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 15:15:27 +02:00
pure-eval.sh \
add tests for nix eval and nix-instantiate
2022-03-16 20:57:18 +02: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 15:15:27 +02:00
repl.sh \
binary-cache-build-remote.sh \
search.sh \
logging.sh \
export.sh \
config.sh \
add.sh \
local-store.sh \
filter-source.sh \
misc.sh \
dump-db.sh \
linux-sandbox.sh \
Add some tests for `drop-supplementary-groups`
2023-05-16 00:41:51 +03: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 15:15:27 +02: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 17:32:53 +02:00
structured-attrs.sh \
rename run to shell in tests
2020-04-30 00:37:21 +03: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 19:50:38 +02:00
brotli.sh \
add tests for zstd compression
2021-04-10 00:13:08 +03:00
zstd.sh \
Add compression level for NARs Based off on @dtzWill's #2276
2021-10-12 09:14:36 +03:00
compression-levels.sh \
Add basic flake tests
2019-05-08 00:22:47 +03: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 12:23:19 +03:00
nix-copy-ssh-ng.sh \
Merge remote-tracking branch 'origin/master' into flakes
2019-08-08 16:49:13 +03:00
post-hook.sh \
Merge remote-tracking branch 'origin/master' into flakes
2019-08-29 17:11:38 +03:00
function-trace.sh \
Move flake-local-settings.sh
2022-07-13 21:51:28 +03:00
flakes/config.sh \
nix-fmt: add command
2022-03-11 15:57:28 +02:00
fmt.sh \
Add test for readFile keeping context
2017-11-11 00:51:34 +02: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 15:15:27 +02:00
why-depends.sh \
Create `nix derivation add` command Also refine `nix derivation show`'s docs very slightly.
2023-02-18 01:37:35 +02:00
derivation-json.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 15:15:27 +02:00
import-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 16:32:14 +02:00
nix_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 15:15:27 +02:00
case-hack.sh \
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 15:32:12 +02: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 02:15:05 +02: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 05:24:51 +03: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 15:15:27 +02:00
db-migration.sh \
tests: Rename nix-profile.sh -> bash-profile.sh
2022-03-02 12:14:31 +02: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 15:15:27 +02:00
pass-as-file.sh \
Add some end-to-end tests for the suggestions
2022-03-04 11:29:48 +02:00
nix-profile.sh \
suggestions.sh \
store info sh renamed
2023-10-17 21:42:10 +03: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 17:31:01 +03:00
fetchClosure.sh \
Fix the name of the completions test
2022-07-12 10:19:05 +03:00
completions.sh \
Add a test for `nix flake show`
2023-01-27 11:13:05 +02:00
flakes/show.sh \
Add command 'nix store path-from-hash-part' This exposes the Store::queryPathFromHashPart() interface in the CLI.
2022-10-18 17:42:06 +03:00
impure-derivations.sh \
Trivial changes from the lazy-trees branch
2022-12-07 13:58:58 +02:00
path-from-hash-part.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 12:34:09 +03: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 20:17:17 +03: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 14:58:42 +03:00
nested-sandboxing.sh \
impure-env.sh
Add support for ‘make installcheck’
2013-11-25 19:47:03 +02:00
Make libcpuid dependency optional with --disable-cpuid
2021-11-28 01:48:04 +02:00
ifeq ($(HAVE_LIBCPUID), 1)
nix_tests += compute-levels.sh
endif
Add support for ‘make installcheck’
2013-11-25 19:47:03 +02: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 18:57:31 +03:00
ifeq ($(ENABLE_BUILD), yes)
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 18:10:54 +03:00
nix_tests += test-libstoreconsumer.sh
ifeq ($(BUILD_SHARED_LIBS), 1)
nix_tests += plugins.sh
endif
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 19:12:18 +03:00
$(d)/test-libstoreconsumer.sh.test $(d)/test-libstoreconsumer.sh.test-debug: \
$(d)/test-libstoreconsumer/test-libstoreconsumer
$(d)/plugins.sh.test $(d)/plugins.sh.test-debug: \
$(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 18:10:54 +03:00
Make `tests/dyn-drv` test dir
2023-04-20 01:49:50 +03:00
install-tests += $(foreach x, $(nix_tests), $(d)/$(x))
Add support for ‘make installcheck’
2013-11-25 19:47:03 +02: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 19:12:18 +03:00
test-clean-files := \
Make `tests/dyn-drv` test dir
2023-04-20 01:49:50 +03:00
$(d)/common/vars-and-functions.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 05:24:51 +03:00
$(d)/config.nix
Add support for ‘make installcheck’
2013-11-25 19:47:03 +02: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 19:12:18 +03:00
clean-files += $(test-clean-files)
test-deps += $(test-clean-files)
Reference in a new issue Copy permalink