[SERVER-75846] Default resmoke runs to running with noPassthrough, or require running with a suite Created: 07/Apr/23 Updated: 16/Jan/24 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Ted Tuckman | Assignee: | [DO NOT ASSIGN] Backlog - DevProd Correctness |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Correctness
|
| Participants: |
| Description |
|
Currently resmoke defaults to doing setting up a standalone node (as the core suite does). It would be good if the default behavior did no setup that was hidden or implicit. Its easy now to rely on behaviors from the default suite in suites where they may not apply when running on evergreen. |
| Comments |
| Comment by Ted Tuckman [ 10/Apr/23 ] | ||
|
I've edited the description to be slightly clearer, does that make more sense now? | ||
| Comment by Alex Neben [ 07/Apr/23 ] | ||
|
I'm a little confused as to the ask here. What is the "extra setup for test runs"? | ||
| Comment by Charlie Swanson [ 07/Apr/23 ] | ||
|
One common scenario we see is that our tests start their own cluster or standalone or whatever, and are supposed to use testDB to connect to that cluster. I believe we use testDB as an idiom to avoid clobbering the global db variable. But because of this it is very easy to accidentally write in your test
When what you meant is
It's almost a force of habit after typing db.runCommand() so many times in other tests. The fact that we default the test suite to "core" and provide a binding to the db object makes these really tricky to debug! The command you issued appears not to be doing anything - and yet it appears in the test logs! What is happening?!? It would be great to make this mistake much harder to make, by forcing developers to select the suite, and so to opt in to having 'db' defined. A linting rule around this would also be good - but typically you wouldn't notice the linter failure until your patch build, after running and debugging it locally - probably experiencing all the pain already. |