Run tests in parallel with ParallelTestRunner (Take 2) - #179
Run tests in parallel with ParallelTestRunner (Take 2)#179christiangnrd wants to merge 13 commits into
Conversation
Split `test/runtests.jl` into per-topic files (core, workers, failures, output, unit, serial, retries) that `runtests(ParallelTestRunner, ARGS)` discovers and runs in parallel workers. Each file's sandbox gets ParallelTestRunner, Test and `utils.jl` via `init_code`. Adjustments needed because the tests now run in worker sandboxes: - The sample test files used by the "basic use" and "subdir use" tests moved to `test/sample_tests/`, which is excluded from discovery and passed explicitly, so nested runs don't recurse into the real suite. - The custom record type is evaluated into `Main` (as on the workers) so it deserializes; a bare `eval` would land in the sandbox module. - `Base.ARGS` in the custom-worker shutdown test replaced with `String[]`. - `@show_if_error` moved to `utils.jl` so every sandbox has it. - The "no workers running" check stays in `runtests.jl`, after the outer run, so it checks the main process rather than a single worker. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This reverts commit 5c5ba64, dropping the debugging println(str) lines from the serial and workers test files. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-authored-by: Mosè Giordano <765740+giordano@users.noreply.github.com>
|
How come the diff is +1,623/-1,700? I'd expect to slightly increase number of lines, not to lose them (as much as I like deleting code, I'm suspicious when this happens in tests) |
Was this maybe when we were using Distributed?
I did a bit of combining testsets to reduce cold worker start times since they're super high on x86 runners. Maybe this should be a follow-up PR, but I split up each change in its own commit to hopefully make it easier to review (3b877c8 to e18227f) |
Quite possibly.
👍 |
2 participants
#178 was automatically closed when I force-pushed to rebase #176 on top of #178 (instead of the other way around)
@giordano I think this is more straightforward than #176, but will cause more conflicts, so it should probably be merged first.