Replies: 1 comment
-
|
Thanks for the question. In theory nextest could support the GNU Make jobserver protocol for this, though an interesting question is whether we'd want the jobserver to be inherited by tests. (Probably not?) See https://www.gnu.org/software/make/manual/html_node/Job-Slots.html Happy to take a draft PR for this. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I understand that this is probably out of scope for nextest itself - so I'll explain some stuff before coming to the question
Current setup
I work in a git with multiple workspaces: backend, frontend, graphics-renderer, native-ffi, wasm-ffi, cli, demo application, and so on. This setup is convenient because everything is tested together. We don't publish any crates which adds to the convenience.
To test everything i have a Zellij multipane with bacon running nextest in each pane for each workspace. This works "well" while developing but obviously not optimal since each nextest runs many cores to optimize, and we kind of break that optimization by running multiple nextest.
Question
Running nextest in a multi-workspace way will probably never be implemented (right?), so my ask here is if there are any ways to improve this? Is anyone else doing something similar? Thanks!
Beta Was this translation helpful? Give feedback.
All reactions