Created Started Cancelled
By: Tom Sydney Kerckhove <syd@cs-syd.eu>
Respect the cores nix gave the build A test suite compiled with -N asks the RTS for every core of the machine it runs on, which inside a nix build is not what the build was given. Nix's cores setting reaches a build only as NIX_BUILD_CORES, so read that, and let it decide how parallel to run when nothing else does. Nix's --max-jobs is not visible to a build at all, so there is nothing to respect there. It narrows, and only narrows. Anything configured explicitly still decides: --jobs, --synchronous, SYDTEST_JOBS, threads in the config file, and --debug all win, so an ambient variable cannot override a config file. More cores than the RTS has capabilities leaves the count alone rather than raising it, because running more tests at once than the RTS can overlap is contention with no parallelism to show for it: a suite not compiled with -N has one capability, and running it 64 ways because the builder has 64 cores would be a change for the worse. The narrowing also happens after the warning about compiling with -N is decided, so a suite stuck on one capability is still told to add it. Zero threads now means every capability rather than an asynchronous runner with no workers. --jobs 0 left nothing to take tests off the queue and the suite died with "thread blocked indefinitely in an STM transaction". Nix documents 0 as "use every core", which is how NIX_BUILD_CORES=0 reaches a build wherever stdenv has not already replaced it with a core count, and the mutation driver's own job counts have always treated it that way, so every route into a thread count now agrees.