WASM: browser-wasm * Release WasmBuildTests don't use hardcoded SDK version

[jozkee]

#114676 hardcoded SdkVersionForWorkloadTesting to 9.0.105, this is not good because it will break as soon as codeflow bumps the global.json version.

See: #115677 (comment) and
arcade codeflow CI: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1057438&view=logs&j=1fa93050-f528-55d3-a351-f8bf9ce5adbf&t=d9dc6d3d-3442-5b70-1296-5b62e29ea209&l=78

cc @ericstj

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[jozkee]

cc @akoeplinger, is there an alternative to updating SdkVersionForWorkloadTesting each time the global.json is updated? This is prone to errors, especially for folks unexperienced with codeflow.

[akoeplinger]

yeah I think we could add some logic to look at SdkVersionForWorkloadTesting and global.json and pick whatever version is higher

[ericstj]

Why do we even have a different version for this? Can it just use whatever SDK is configured for the repo?

[akoeplinger]

No, the repo SDK is updated quite infrequently, the point of these tests is to test against the the latest SDK. At least that's how it works in main, for servicing it basically flips around since we usually don't have an sdk -> runtime flow so the SDK in global.json moves ahead.

[lewing]

We could update the logic to use dotnet/msbuild@2013004 and use the Max (sdk flow, global.json)

[lewing]

We could update the logic to use dotnet/msbuild@2013004 and use the Max (sdk flow, global.json)

this sounded easy until I remembered how fun it is to try to deal with prerelease versions in msbuild