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
..
clean.mk
common-test.sh
cxx-big-literal.mk	Dedup some markdown -> C++ big literal stuff in build system	2023-05-15 10:38:11 -04:00
debug-test.sh	Harden tests' bash	2023-03-08 10:26:30 -05:00
disable-tests.mk	Add ./configure --disable-tests option	2023-02-24 09:50:21 +01:00
functions.mk
install.mk
lib.mk	Introduce notion of a test group, use for CA tests	2023-07-18 09:31:13 -04:00
libraries.mk	fix: build aarch64-darwin	2023-03-18 17:53:45 -04:00
patterns.mk	Enable -Werror=switch-enum	2023-04-03 18:45:20 +02:00
precompiled-headers.mk
programs.mk
run-test.sh	Remove "unexpected EOF" retry hack	2023-03-15 10:59:10 +01:00
templates.mk
tests.mk	Introduce notion of a test group, use for CA tests	2023-07-18 09:31:13 -04:00
tracing.mk