Installing `wasm-tools` Workload Changes Test Results

[TanayParikh]

Some repo tests start failing once the wasm-tools workload is installed.

Repro'd in the CI and locally.

Steps:

./restore.sh
./build.sh
./artifacts/bin/redist/Debug/dotnet/dotnet workload install --skip-manifest-update --no-cache wasm-tools
./artifacts/bin/redist/Debug/dotnet/dotnet test --filter Given_multi_target_It_should_get_suggested_workload_by_GetRequiredWorkloads_target ./src/Tests/Microsoft.NET.Build.Tests/Microsoft.NET.Build.Tests.csproj

This test fails. Now uninstall the workload and test again.

./artifacts/bin/redist/Debug/dotnet/dotnet workload uninstall wasm-tools
./artifacts/bin/redist/Debug/dotnet/dotnet test --filter Given_multi_target_It_should_get_suggested_workload_by_GetRequiredWorkloads_target ./src/Tests/Microsoft.NET.Build.Tests/Microsoft.NET.Build.Tests.csproj

The test now passes. There are several other tests that behave differently based on whether the wasm-tools workload is installed or not.

cc/ @radical

[TanayParikh]

Note, to repro this issue and see the full set of failing tests due to the wasm-tools workload install, add the following to the CI:

        - script: $(Build.SourcesDirectory)/artifacts/bin/redist/$(_BuildConfig)/dotnet/dotnet workload install wasm-tools
          displayName: Install wasm-tools Workload

between the build and helix test steps (after line 79):

https://github.com/dotnet/sdk/blob/5ab75c380bcca388c4e049eeedf3faf80d59e6df/eng/build.yml#L68-L89

[radical]

cc @lewing

[marcpopMSFT]

@TanayParikh What are the errors you see when the workload is installed? My local tests aren't working so I can't try out the repro.

[TanayParikh]

What are the errors you see when the workload is installed?

Certain tests were failing after the wasm tools workload was installed (which weren't failing prior to the installation). I don't remember the specific tests, however this change and CI run should expose the failing tests.

https://dev.azure.com/dnceng/public/_build/results?buildId=1511138&view=results

[marcpopMSFT]

Let's try again but with --skip-manifest-update enabled to see if that changes the behavior. In theory, we could even use rollback files to pin to a specific version to have more reliable behavior but I'd guess it was a manifest update that impacted the tests: https://github.com/dotnet/sdk/pull/23251

[TanayParikh]

--skip-manifest-update enabled to see if that changes the behavior.

Hmm, I've tried that in the past but didn't have much luck: https://github.com/dotnet/sdk/pull/22977

It ended up taking stale packages which caused other issues.