(maint) Add rake task for parallelizing specs.#2416
Conversation
|
Would it be an idea to use https://github.com/grosser/parallel_tests or is this to prevent external dependancies? |
|
There's two problems we have with parallel_tests. The first is we have too many spec files and they get passed on rpsec's command line, causing problems on Windows due to command line length limitations. Hence the existence of the 'rspec_runner' script which takes a single file as input containing a list of spec files to run. The second is that parallel_tests will run all the specs in a single process if you give it a process count of 1. What we'd like for Travis, since we're seeing rspec getting killed for rather insane memory usage, is recycle the process every ~X number of specs (with these changes, the rspec process gets recycled after approximately every 1000 specs). |
|
Cool, just curious, looking forward to more stable Travis 👍 |
|
CLA signed by all contributors. |
Adding a 'parallel:spec' task that will group specs and then run those groups in a parallel set of processes. By default, parallel:spec will bunch the specs into groups of approximately 1000 and concurrently run each group up to the number of processors reported by facter. The task takes two parameters: process_count and group_size. Running with a process_count of 1 (parallel:spec[1]) will behave like the existing 'spec' task, except it will still group the tests and recycle the spec running process between groups. This has the added benefit of limiting the spec running process' working set, at the cost of being a little slower.
(maint) Add rake task for parallelizing specs.
Adding a 'parallel:spec' task that will group specs and then run those
groups in a parallel set of processes.
By default, parallel:spec will bunch the specs into groups of
approximately 1000 and concurrently run each group up to the number of
processors reported by facter.
The task takes two parameters: process_count and group_size.
Running with a process_count of 1 (parallel:spec[1]) will behave like
the existing 'spec' task, except it will still group the tests and
recycle the spec running process between groups. This has the added
benefit of limiting the spec running process' working set, at the cost
of being a little slower.