Enable container test execution

[v-wuzhai]

No description provided.

[v-wuzhai]

We're encountering test failures because dotnet workload restore attempts to write to paths that are not writable in containerized environments. This appears to be a common limitation in CI scenarios.

StdErr: Unhandled exception: Read-only file system : '/root/helix/work/correlation/d/metadata' , but found 1 (difference of 1).

@dotnet/domestic-cat @marcpopMSFT — is there a recommended workaround or best practice for handling this?

[Forgind]

Can you clarify which part is going wrong? There's normally a metadata folder somewhere next to process path, so we're expecting to be able to access the spot right next to dotnet.exe or dotnet on linux. You can move the standard workload metadata folder that we write to if you set user local.

[v-wuzhai]

Can you clarify which part is going wrong? There's normally a metadata folder somewhere next to process path, so we're expecting to be able to access the spot right next to dotnet.exe or dotnet on linux. You can move the standard workload metadata folder that we write to if you set user local.

Thanks for the follow-up! Just to clarify, the issue is happening in the context of the two tests in this PR:

1. ProjectsThatDoNotSupportWorkloadsAreNotInspected
2. ProjectsThatDoNotSupportWorkloadsAndAreTransitivelyReferencedDoNotBreakTheBuild

These tests are failing in our containerized CI environment due to dotnet workload restore attempting to write to a read-only path:

Unhandled exception: Read-only file system : '/root/helix/work/correlation/d/metadata'
👉 Full pipeline failure log here

I tried setting the following environment variables in the test setup:

1. .WithEnvironmentVariable("DOTNET_CLI_HOME", cliHome)
2. .WithEnvironmentVariable("DOTNET_WORKLOAD_METADATA_DIR", metadataDir)
3. .WithEnvironmentVariable("DOTNET_SKIP_WORKLOAD_VERIFICATION", "true")

However, the error still occurs, which suggests that some part of the workload infrastructure is still trying to write to the default location. Is there another recommended way to fully redirect or disable workload-related writes in this scenario?

[Forgind]

I believe that if you create a userlocal file, that is, a 0-byte file here (like C:\Program Files\dotnet\metadata\workloads\10.0.100\userlocal), it will only write to a directory under your DOTNET_CLI_HOME folder.

I'm not really sure what's being written. Are these from updating advertising manifests? If so, perhaps we could disable that?

[v-wuzhai]

I believe that if you create a userlocal file, that is, a 0-byte file here (like C:\Program Files\dotnet\metadata\workloads\10.0.100\userlocal), it will only write to a directory under your DOTNET_CLI_HOME folder.

I'm not really sure what's being written. Are these from updating advertising manifests? If so, perhaps we could disable that?

Thanks, that’s super helpful! I wasn’t aware of the userlocal file trick — I’ll try creating a 0-byte file at:

<dotnet-root>/metadata/workloads/<sdk-feature-band>/userlocal
and see if that redirects all writes to DOTNET_CLI_HOME as expected.

[v-wuzhai]

@Forgind Thanks for the suggestion! I looked into the userlocal file workaround, but in my case, DOTNET_ROOT is set to a read-only path (/root/helix/work/correlation/d), and I don’t have permission to create files under it. So unfortunately, I can’t create the metadata/.../userlocal file there.

Unless there's a better workaround, I might have to temporarily skip these two.

[Forgind]

I looked into the code a bit, and the only thing that I can think of that should be being written is advertising manifests, but unfortunately there isn't really an option to disable that, so I don't know that there's a 'natural' answer.

You could probably add a way to opt out of updating advertising manifests from the workload restore command, but I think that would be too much effort for something like this, so I think disabling it is the right choice.