The future git tag variant was introduced in SERVER-60210 to simulate the next FCV upgrade. It does this by setting our latest FCV to a very high version (100.0), which will bump our current latest down to lastContinuous. For instance, if master is tagged with 7.1, the future git tag FCV constants look like:

latestFCV: 100.0
lastContinuousFCV: 7.1
lastLTSFCV: 7.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.