* [vcpkg] Update vcpkg tool version 2021-05-05
* [vcpkg] Hotfix bug in Microsoft/vcpkg-tool#34
* [vcpkg-ci] Ignore results from non-target triplets
* [protobuf] Fix regression introduced in #16904
* [vcpkg] Fix bug where 'staticcrt' was ignored
Co-authored-by: Robert Schumacher <ras0219@outlook.com>
This changes our PR builds to treat 'fail' in the ci.baseline.txt as 'skip' instead of using tombstones.
We currently have large numbers of spurious failures that get enshrined in PRs through no fault of a PR author, removing the tombstones concept will fix those by allowing the user to retry. This does mean we accept some risk of not detecting when a port is 'fixed', but that failure is reasonable for us to handle after we see it in CI, but that seems worth it given that it lets us get rid of the tombstone concept.
This also helps out the binary caching feature, because we don't have to figure out how to productize tombstones.
* Adds scripts to generate scale sets for testing Linux.
* Note workaround for https://github.com/microsoft/azure-pipelines-agent/pull/2929
* Switches Windows validation to 'Spot' VMs.
* Opens the git port 9418.
* Removes provisioning of the no longer used 'logs' file share.
* Changes Azure region to 'westus2', which is cheaper.
* Adds +x to all the scripts in scripts/azure-pipelines.
* Use 'xml-results' for all platforms instead of 'raw xml results' on Windows.
Included is a script that sets up all vcpkg's Azure infrastructure for Windows PR tests, and several updates to baselines. The baseline updates are generally caused by an updated copy of the MSVC++ compiler caused by updating the VMs, but some are caused by missed failures only detected now because this did a cleared out archives directory first.
Some of the build infrastructure isn't what I'd call 'pretty' (e.g. we're split into more scripts and such than I'd like) but this mirrors how our existing PR system works.
It is expected that the existing vcpkg Windows PR system will hate these baseline updates so we'll need to merge this, then remove that (duplicate) workflow immediately afterwards, then delete all the Windows VMs powering the old infrastructure.
