Add interpreter pipeline

[eduardo-vp]

Adding a pipeline that runs pri1 tests using the interpreter.

After taking a look with @janvorli, updated src/tests/Common/CLRTest.Execute.Bash.targets since there were two BashCLRTestLaunchCmds blocks under the condition '$(CLRTestKind)' == 'BuildAndRun' And '$(TargetOS)' != 'browser' And '$(TargetOS)' != 'android', one for arm64 and one for everything but arm64. However, turns out it's no longer necessary to split in two separate blocks anymore, the logic should be the same one for both. In particular, the ability to use the interpreter and the support for lldb was present in only one of them whereas it should be present in both.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[eduardo-vp]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[eduardo-vp]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull Request Overview

This PR adds support for running pri1 tests using the interpreter by introducing a dedicated pipeline and wiring a RunInterpreter flag through Helix publishing.

• Extended helixpublishwitharcade.proj to define and consume a _RunInterpreter MSBuild property and emit Helix pre-commands.
• Created eng/pipelines/coreclr/interpreter.yml to build CoreCLR in debug/release/checked configurations and invoke tests with runInterpreter: true.
• Updated common templates (send-to-helix-step.yml, run-test-job.yml) to accept and forward the runInterpreter parameter.

Reviewed Changes

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

File	Description
src/tests/Common/helixpublishwitharcade.proj	Added _RunInterpreter property and corresponding Windows/Linux Helix pre-commands.
eng/pipelines/coreclr/interpreter.yml	New pipeline file for interpreter-based builds and test runs.
eng/pipelines/common/templates/runtimes/send-to-helix-step.yml	Added runInterpreter parameter and mapped it to _RunInterpreter.
eng/pipelines/common/templates/runtimes/run-test-job.yml	Introduced runInterpreter parameter with default false and propagated it.

Comments suppressed due to low confidence (1)

eng/pipelines/coreclr/interpreter.yml:16

• [nitpick] The pipeline duplicates the platform matrix definitions across multiple build and test jobs. Consider extracting the platform lists into a shared variable or template to reduce duplication and make future updates easier.

      - template: /eng/pipelines/common/platform-matrix.yml

[eduardo-vp]

/azp run runtime-interpreter-tests-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

/azp run runtime-interpreter-tests-ci

Can we rename this to runtime-interpreter-tests or just runtime-interpreter for consistency? We do not have -ci suffix in names of any existing runs. (Noticed in #116310 (comment).)

[eduardo-vp]

/azp list

[azure-pipelines]

CI/CD Pipelines for this repository:

• runtime-coreclr outerloop
• runtime-coreclr jitstress
• runtime-coreclr jitstressregs
• runtime-coreclr jitstress2-jitstressregs
• runtime-coreclr gcstress0x3-gcstress0xc
• runtime-coreclr gcstress-extra
• runtime-coreclr r2r-extra
• runtime-coreclr jitstress-isas-x86
• runtime-coreclr jitstress-isas-arm
• runtime-coreclr jitstressregs-x86
• runtime-coreclr libraries-jitstressregs
• runtime-coreclr libraries-jitstress2-jitstressregs
• runtime-coreclr r2r
• runtime-coreclr runincontext
• runtime-coreclr crossgen2
• runtime-libraries-coreclr outerloop
• runtime-libraries-coreclr outerloop-windows
• runtime-libraries-coreclr outerloop-linux
• runtime-libraries-coreclr outerloop-osx
• runtime
• runtime-libraries enterprise-linux
• runtime-libraries stress-http
• runtime-libraries stress-ssl
• runtime-dev-innerloop
• runtime-coreclr crossgen2 outerloop
• coreclr-release-outerloop-nightly
• runtime-coreclr crossgen2-composite
• runtime-jit-experimental
• runtime-coreclr libraries-jitstress
• dotnet-linker-tests
• runtime-coreclr ilasm
• runtime-coreclr crossgen2-composite gcstress
• runtime-coreclr pgo
• runtime-coreclr libraries-pgo
• Antigen
• runtime-community
• Fuzzlyn
• runtime-coreclr superpmi-replay
• runtime-wasm
• runtime-coreclr superpmi-diffs
• runtime-coreclr superpmi-asmdiffs-checked-release
• runtime-extra-platforms
• jit-cfg
• runtime-wasm-perf
• runtime-llvm
• runtime-coreclr jitstress-random
• runtime-coreclr libraries-jitstress-random
• runtime-android-grpc-client-tests
• runtime-wasm-non-libtests
• runtime-android
• runtime-androidemulator
• runtime-ioslike
• runtime-ioslikesimulator
• runtime-linuxbionic
• runtime-maccatalyst
• runtime-coreclr pgostress
• runtime-coreclr jitstress-isas-avx512
• runtime-libraries-mono outerloop
• runtime-sanitized
• runtime-wasm-dbgtests
• runtime-wasm-optional
• runtime-nativeaot-outerloop
• runtime-coreclr superpmi-collect-test
• runtime-diagnostics
• runtime-interpreter

[eduardo-vp]

/azp run runtime-interpreter

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

This is triggering and causing a lot of failures on most (all?) PRs now. For example, #109006 and #116471. Could you please look into it and switch it to manual trigger?

[jkotas]

Submitted revert #117234

[mangod9]

yeah this was always meant to be manually triggered initially. Eduardo please check why it's affecting PRs.

[jkoritzinsky]

The manual trigger setting needs to be set up by Eng Services First Responder. We can't do it ourselves.