Add interpreter SOS leg to runtime-diagnostics pipeline

[max-charlamb]

Summary

Adds an opt-in Interpreter SOS test leg to runtime-diagnostics.yml that exercises the diagnostics-side SOSInterpreterTests.InterpreterStackTest against a Checked CoreCLR drop. FEATURE_INTERPRETER is only compiled into Debug/Checked CoreCLR, so the existing Release build leg cannot run this test.

Companion diagnostics PR: dotnet/diagnostics#5829.

Changes

eng/pipelines/diagnostics/runtime-diag-job.yml

• New testInterpreter parameter (default false).
• New _TestInterpreterArgs derived variable, set to -testInterpreter when the parameter is true.
• Forwarded to the diagnostics build script alongside the existing -useCdac / -noFallback flags.
• Default-false invocation is identical to today; existing test legs are unaffected.

eng/pipelines/runtime-diagnostics.yml

• New build leg that produces a Checked CoreCLR (libs/SDK stay Release: -c Debug -rc Checked -lc $(_BuildConfig)). Distinct artifact name (..._coreclr_Checked) so it does not collide with the existing Release leg.
• New Interpreter test job modelled on the existing cDAC job:
  • Depends on the new Checked build leg.
  • Downloads the Checked artifact into $(Build.SourcesDirectory)/artifacts/runtime.
  • Only this job sets testInterpreter: true.
  • Keeps useCdac: true, classFilter: SOS.

The existing cDAC / cDAC_no_fallback / DAC test jobs and the existing Release build leg are unchanged.

Activation flow

When the new leg runs, runtime-diag-job.yml invokes the diagnostics build script with -testInterpreter, which exports SOS_TEST_INTERPRETER=true. SOSRunner (in the diagnostics PR) sees config.TestInterpreter == true and sets DOTNET_Interpreter=InterpTestMethod* on the debuggee process. The debuggee csproj declares <InterpreterTest>true</InterpreterTest>; the rest of the wiring is in the diagnostics PR.

Validation

Manually queued the runtime-diagnostics pipeline in dnceng-public/public against this branch with parameter diagnosticsBranch=dev/max-charlamb/sos-interpreter-tests so the pipeline checks out the companion diagnostics PR.

Expected:

• New Interpreter_windows_x64_release job runs and passes.
• Existing cDAC / cDAC_no_fallback / DAC jobs continue passing — they do not set testInterpreter and produce the same script invocation as today.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR extends the runtime-diagnostics Azure Pipelines definition to add a new Interpreter SOS test leg that runs SOS diagnostics tests against a Checked CoreCLR build (required because FEATURE_INTERPRETER isn’t present in Release CoreCLR drops). It also updates the shared diagnostics job template to optionally pass a new -testInterpreter flag through to the diagnostics build script.

Changes:

• Add a new Checked CoreCLR build job that publishes a distinct runtime artifact (..._coreclr_Checked) to avoid colliding with the existing Release artifact.
• Add a new Interpreter test job (modeled after the existing cDAC job) that depends on the Checked build output and is the only job that sets testInterpreter: true.
• Extend runtime-diag-job.yml with a testInterpreter parameter and plumb it through as -testInterpreter when enabled.

Reviewed changes

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

File	Description
eng/pipelines/runtime-diagnostics.yml	Adds a Checked CoreCLR build artifact + a new Interpreter SOS test job that consumes it.
eng/pipelines/diagnostics/runtime-diag-job.yml	Adds testInterpreter parameter and forwards it as -testInterpreter to the diagnostics build script.

[BrzVlad]

Note that here you can pass -clrinterpreter (which enables it in release build as well), if you believe it is more consistent to test it directly in release.