[SERVER-81251] Ensure future git tag variant always runs lastContinuous suites Created: 20/Sep/23 Updated: 26/Jan/24 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 8.0 Required |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Xuerui Fa | Assignee: | Steve Gross |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Build
|
||||
| Participants: | |||||
| Description |
|
The future git tag variant was introduced in latestFCV: 100.0 This effectively tests the next release, as we are running tests on the “next version” before actually upgrading. While debugging, I noticed that the future git tag variant wasn’t running the lastContinuous suite on waterfall, which would’ve tested a mixed version set between 100.0 and 7.1 nodes. Instead, it was only running the lastLTS suite, which tests between 100.0 and 7.0. This led to errors not being caught until we actually attempted the upgrade. My suspicion is that while our latest FCV was 7.1, both our lastContinuous and lastLTS FCVs were 7.0. As a result, the test infrastructure had logic to skip the lastContinuous suite, and this seems to have erroneously been applied to the future git tag variant as well. We can see that after upgrading to 7.2 on master, we began running the lastContinuous suites on evergreen again. The future git tag variant should always have a lastContinuous to run against (since its lastContinuous would be the current latest on master), and so we should always run the lastContinuous suite in the future git tag variant. |