[SERVER-23489] Capability to provide the workload schedule to the concurrency test schedule Created: 04/Apr/16 Updated: 01/Aug/18 Resolved: 01/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | 3.3.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jonathan Abrahams | Assignee: | DO NOT USE - Backlog - Test Infrastructure Group (TIG) |
| Resolution: | Done | Votes: | 0 |
| Labels: | tig-concurrency | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backport Requested: |
v3.2
|
||||
| Participants: | |||||
| Description |
|
The concurrency test suite randomizes the schedule of tests that run in the execution mode (serial, parallel or composed). The subsequent workload schedule is then printed out, permitting a rerun of that schedule by patching runner.js. The proposed work would abstract the workload schedule such that it could be defined at a higher level, perhaps in fsm_all.js, fsm_all_composed.js, fsm_all_simultaneous.js, etc. |
| Comments |
| Comment by Max Hirschhorn [ 01/Aug/18 ] | |
|
A list of files can now be specified to resmoke.py when running the concurrency and will be interpreted as running the FSM workloads in the specified order (one at a time).
For the concurrency_simultaneous.yml test suite, the list of files is interpreted as a single FSM workload group (all at once). | |
| Comment by Jonathan Abrahams [ 04/Apr/16 ] | |
|
I have changed the scope of this ticket to support rerunning a workload schedule, without modifying runner.js. |