Don't force shipping versions to be used in VMR builds #11625
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes failures like https://dev.azure.com/dnceng-public/public/_build/results?buildId=991991&view=results
Context
When MSBuild is being built in the VMR, sometimes later-built packages can end up with different versions than earlier-built packages. That's not good, but it doesn't cause failures.
However, these later-built packages can have different (higher) versions of dependency projects that had already been built with the lower versions. This causes downgrade failures like the following intermittently for any VMR jobs triggered around the end of the PST workday:
Changes Made
Don't build MSBuild with shipping versions in the VMR unless the VMR passes an official build ID.
Testing
Local validation
Notes
This needs to be in the VMR before we switch to flat flow as after that switch, we'll move source-build to use the same versioning rules as unified-build and they'll start getting destabilized in the same way.