Repository navigation
WASM: browser-wasm * Release WasmBuildTests don't use hardcoded SDK version #116451
Description
#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
Activity
dotnet-policy-service commentedon Jun 9, 2025
Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.
jozkee commentedon Jun 10, 2025
cc @akoeplinger, is there an alternative to updating
SdkVersionForWorkloadTestingeach time the global.json is updated? This is prone to errors, especially for folks unexperienced with codeflow.akoeplinger commentedon Jun 10, 2025
yeah I think we could add some logic to look at SdkVersionForWorkloadTesting and global.json and pick whatever version is higher
ericstj commentedon Jun 10, 2025
Why do we even have a different version for this? Can it just use whatever SDK is configured for the repo?
akoeplinger commentedon Jun 10, 2025
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 commentedon Jun 16, 2025
We could update the logic to use dotnet/msbuild@2013004 and use the Max (sdk flow, global.json)
lewing commentedon Jun 21, 2025
this sounded easy until I remembered how fun it is to try to deal with prerelease versions in msbuild