[SERVER-48217] Allow the background validation hooks number of jobs or frequency to be modified with resmoke for local development Created: 14/May/20 Updated: 06/Dec/22 Resolved: 08/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Gregory Wlodarek | Assignee: | Backlog - Server Tooling and Methods (STM) (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | tig-resmoke, undo-candidate | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Server Tooling & Methods
|
||||||||
| Participants: | |||||||||
| Linked BF Score: | 19 | ||||||||
| Description |
|
We've been seeing a rise in the number of build failures related to validation rise recently. Reproducing these failures is often very time-consuming. For example, I had a build failure related to validation failing that I wasn't able to reproduce until I changed the hook script to run more validation threads concurrently. It would be a useful feature to be able to change the number of validation jobs or their frequency for build failure reproduction from the resmoke invocation. |
| Comments |
| Comment by Brooke Miller [ 08/Jun/20 ] |
|
STM doesn't have immediate plans to work on this. Please feel free to re-open if needed. |
| Comment by Robert Guo (Inactive) [ 21/May/20 ] |
|
Per offline discussions with Gregory, I think we should look into adding test coverage for stressing validate(). The hook is meant to be lightweight and ideally not catch issues that only shows up when there is resource contention. A concurrency workload that calls validate() would be a good way to achieve that. |
| Comment by Gregory Wlodarek [ 18/May/20 ] |
|
brooke.miller, sure I've attached the build failure. |
| Comment by Brooke Miller [ 18/May/20 ] |
|
Hey gregory.wlodarek, could you provide the link to the BF that you mentioned above? We're working with Undo to make many Evergreen failures recorded so that they don't need to be reproduced. This seems like a good candidate to test this, once we finish PM-1757, which will be completed shortly. |