[Draft] Try installing Dotnet SDK on Helix Runners for SPMI Benchmark Collections

[adamperlin]

Requires a patched version of dotnet/performance to set the TLS version in powershell on windows.
dotnet/performance PR here: dotnet/performance#5088

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @dotnet/jit-contrib
See info in area-owners.md if you want to be subscribed.

[adamperlin]

/azp run runtime-coreclr superpmi-collect-test

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[adamperlin]

@EgorBo feedback should be addressed!

[EgorBo]

Thanks!

[Copilot]

Pull request overview

This draft PR attempts to move the dotnet SDK installation from the setup phase (superpmi_collect_setup.py) to the execution phase (superpmi_benchmarks.py) for SPMI benchmark collections on Helix runners. The PR aims to set up NuGet cache locations to avoid filling up limited OS disk space on Helix machines.

Changes:

• Removed dotnet SDK installation logic from superpmi_collect_setup.py
• Added NuGet environment variables configuration in superpmi_benchmarks.py
• Moved dotnet SDK installation to occur at runtime in superpmi_benchmarks.py

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/coreclr/scripts/superpmi_collect_setup.py	Removed the dotnet SDK installation code that used ChangeDir and installed dotnet during setup phase
src/coreclr/scripts/superpmi_benchmarks.py	Added NuGet cache environment variables, defined empty install_dotnet_sdk function, and added inline dotnet SDK installation command in build_and_run function

Comments suppressed due to low confidence (4)

src/coreclr/scripts/superpmi_benchmarks.py:151

• The function install_dotnet_sdk is defined but has no implementation (empty body). This function appears to be unused in the current code. Consider removing this function definition entirely, or if it was intended to be used in place of the inline dotnet installation code at lines 196-205, then implement it properly and call it from build_and_run.

def build_and_run(coreclr_args, output_mch_name):
"""Build the microbenchmarks/real-world and run them under "superpmi collect"
Args:
coreclr_args (CoreClrArguments): Arguments use to drive
output_mch_name (string): Name of output mch file name
"""

src/coreclr/scripts/superpmi_benchmarks.py:205

• The dotnet installation command is missing the --install-dir parameter. The removed code in superpmi_collect_setup.py (lines 406-418) explicitly specified --install-dir pointing to dotnet_directory. Without this parameter, the dotnet.py script may install to a default location, which would cause the subsequent run_command([dotnet_exe, "--info"]) at line 208 to fail because dotnet_exe is constructed as os.path.join(dotnet_directory, "dotnet") where dotnet_directory is os.path.join(performance_directory, "tools", "dotnet", arch). Add "--install-dir" and the dotnet_directory path to the command arguments.

 "--channels",
"main",
"--verbose"])
# Start with a "dotnet --info" to see what we've got.
run_command([dotnet_exe, "--info"])
tfm = "net11.0"
os.environ["PERFLAB_TARGET_FRAMEWORKS"] = tfm

src/coreclr/scripts/superpmi_benchmarks.py:205

• The call to make_executable(dotnet_exe) appears to have been removed. On non-Windows platforms, the dotnet executable may need execute permissions to be set after installation. This was previously done before the dotnet installation logic moved from superpmi_collect_setup.py to this file. Consider adding make_executable(dotnet_exe) after the dotnet installation at line 205, before attempting to run dotnet --info at line 208.
  src/coreclr/scripts/superpmi_benchmarks.py:202
• Inconsistent indentation: the arch parameter at line 202 has extra indentation compared to the other arguments in the command list. It should be aligned with dotnet_script and "install" at the same indentation level as line 199-201.

[EgorBo]

These files aren't participating in the CI build, so I'm going to merge as is.

[EgorBo]

/ba-g "changes in these files shouldn't trigger any pipeline"