John Ericson 259e328de8 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-18 09:31:13 -04:00
..
build-dry.sh
build-with-garbage-path.sh
build.sh
common.sh
concurrent-builds.sh
config.nix.in
content-addressed.nix
derivation-json.sh	Gate experimental features in DerivationOutput::fromJSON	2023-04-17 17:36:12 -04:00
duplicate-realisation-in-closure.sh
flake.nix
gc.sh
import-derivation.sh
local.mk	Introduce notion of a test group, use for CA tests	2023-07-18 09:31:13 -04:00
new-build-cmd.sh
nix-copy.sh
nix-run.sh
nix-shell.sh
nondeterministic.nix
post-hook.sh
racy.nix
recursive.sh
repl.sh
selfref-gc.sh
signatures.sh
substitute.sh
why-depends.sh