Enable Helix Job Monitor for the runtime pipeline

[premun]

• Add useHelixMonitor parameter to all helix pipeline templates
• Enable Helix Monitor in runtime.yml for all test legs
• Add helix-job-monitor.yml template job at the top of the Build stage
• Add Microsoft.DotNet.Helix.JobMonitor dependency (same version as Arcade)
• Pass EnableHelixJobMonitor MSBuild property through send-to-helix

dotnet/arcade#16731

[dotnet-policy-service]

Tagging subscribers to this area: @akoeplinger, @matouskozak, @simonrozsival
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR wires up Helix Job Monitor support across the runtime Azure DevOps pipelines by introducing a useHelixMonitor parameter through the relevant YAML templates, enabling it for the runtime pipeline test legs, and adding the Helix Job Monitor .NET tool/dependency so the monitor job can run.

Changes:

• Add a HelixJobMonitor job to eng/pipelines/runtime.yml (Build stage) using the shared eng/common template.
• Plumb a useHelixMonitor parameter through Helix-related pipeline templates and pass /p:EnableHelixJobMonitor=... through the various “send to helix” paths.
• Add Microsoft.DotNet.Helix.JobMonitor tool/dependency and pin it in .config/dotnet-tools.json.

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
eng/Version.Details.xml	Adds the Microsoft.DotNet.Helix.JobMonitor toolset dependency entry.
eng/Version.Details.props	Adds version properties for the Helix Job Monitor dependency.
eng/pipelines/runtime.yml	Adds the Helix Job Monitor job and enables useHelixMonitor: true across runtime pipeline test legs.
eng/pipelines/libraries/run-test-job.yml	Introduces useHelixMonitor parameter and forwards it into the libraries Helix submission step.
eng/pipelines/libraries/helix.yml	Accepts useHelixMonitor and passes /p:EnableHelixJobMonitor=... into sendtohelix.proj.
eng/pipelines/installer/helix.yml	Adds useHelixMonitor, but currently passes UseHelixMonitor into /eng/common/templates/steps/send-to-helix.yml (template parameter mismatch; needs fix).
eng/pipelines/coreclr/nativeaot-post-build-steps.yml	Adds useHelixMonitor pass-through to the shared runtime test+Helix submit template.
eng/pipelines/common/templates/wasm-runtime-tests.yml	Adds and forwards useHelixMonitor into the Helix submission path.
eng/pipelines/common/templates/wasm-library-tests.yml	Adds and forwards useHelixMonitor into the Helix submission path.
eng/pipelines/common/templates/wasm-library-aot-tests.yml	Adds and forwards useHelixMonitor into nested wasm templates.
eng/pipelines/common/templates/wasm-coreclr-library-tests.yml	Adds and forwards useHelixMonitor into the Helix submission path.
eng/pipelines/common/templates/simple-wasm-build-tests.yml	Adds and forwards useHelixMonitor into the Helix submission path for WBT scenarios.
eng/pipelines/common/templates/runtimes/send-to-helix-step.yml	Adds useHelixMonitor and includes /p:EnableHelixJobMonitor=... in the computed send parameters.
eng/pipelines/common/templates/runtimes/run-test-job.yml	Adds useHelixMonitor parameter and forwards it to send-to-helix-step.yml.
eng/pipelines/common/templates/runtimes/build-runtime-tests-and-send-to-helix.yml	Adds useHelixMonitor parameter and forwards it to send-to-helix-step.yml.
eng/pipelines/common/templates/browser-wasm-coreclr-build-tests.yml	Hard-enables useHelixMonitor: true for the CoreCLR Wasm.Build.Tests Helix submission.
eng/pipelines/common/templates/browser-wasm-build-tests.yml	Adds and forwards useHelixMonitor for non-CoreCLR WBT Helix submissions.
.config/dotnet-tools.json	Adds the microsoft.dotnet.helix.jobmonitor tool entry and pins its version.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 18 out of 19 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 18 out of 19 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

eng/pipelines/common/templates/browser-wasm-coreclr-build-tests.yml:145

• This template hard-codes useHelixMonitor: true when invoking the libraries Helix template. Since other Helix templates were updated to accept a useHelixMonitor parameter (defaulting to false) and runtime.yml is now explicitly setting it, this hard-coded true makes the behavior inconsistent and harder to roll back/experiment with.

Consider adding a useHelixMonitor parameter to this template (default false) and threading it through instead of hard-coding true.

              testRunNamePrefixSuffix: CoreCLR_$(_BuildConfig)_$(_hostedOs)
              extraHelixArguments: /p:BrowserHost=$(_hostedOs)
              scenarios:
              - buildwasmapps
              useHelixMonitor: true

[Copilot]

Pull request overview

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

Suppressed comments (5)

eng/Version.Details.xml:73

• The Microsoft.DotNet.GenAPI dependency now points at a SHA (b25932e8...) that appears to be from dotnet/arcade, but the dependency Uri is https://github.com/dotnet/dotnet. Version.Details.xml entries should use a commit SHA from the same repo as the Uri; as-is this is inconsistent with the mapping at the top of the file and will make dependency tracking incorrect.

    <Dependency Name="Microsoft.DotNet.GenAPI" Version="11.0.0-beta.26363.117">
      <Uri>https://github.com/dotnet/dotnet</Uri>
      <Sha>b25932e8d128b5242f1d89691f8e8171b82774c0</Sha>
    </Dependency>

eng/Version.Details.props:10

• MicrosoftDotNetHelixJobMonitorPackageVersion is set to 11.0.0-beta.26330.2, but eng/Version.Details.xml pins Microsoft.DotNet.Helix.JobMonitor to 11.0.0-beta.26363.117. Having these out of sync is likely to cause confusion and makes it unclear which version is intended to be used.

    <!-- dotnet-arcade dependencies -->
    <MicrosoftDotNetHelixJobMonitorPackageVersion>11.0.0-beta.26330.2</MicrosoftDotNetHelixJobMonitorPackageVersion>
    <!-- dotnet-dotnet dependencies -->

eng/pipelines/common/variables.yml:50

• enableHelixJobMonitor is defaulted to true for all pipelines. When enabled, the Helix send step is configured to not wait for work item completion and relies on the stage-level HelixJobMonitor job (which requires HELIX_ACCESSTOKEN). In public builds that don't have HelixApiAccessToken, this is likely to fail the monitor job (or leave test results unreported). Consider scoping the default to internal builds only (or default false and opt-in per pipeline).

- name: enableHelixJobMonitor
  value: true

eng/pipelines/runtime.yml:73

• The HelixJobMonitor job is enabled solely based on enableHelixJobMonitor, but it is always passed $(HelixApiAccessToken). On public builds this variable typically isn't available, and the job monitor template requires HELIX_ACCESSTOKEN. This can break public PR validation (and, when EnableHelixJobMonitor is true, can also mean Helix submissions don't wait for completion).

      - ${{ if eq(variables['enableHelixJobMonitor'], true) }}:
        - template: /eng/common/core-templates/job/helix-job-monitor.yml
          parameters:
            helixAccessToken: $(HelixApiAccessToken)
            timeoutInMinutes: 540

.config/dotnet-tools.json:34

• The dotnet tool manifest pins microsoft.dotnet.helix.jobmonitor to 11.0.0-beta.26381.1, but eng/Version.Details.xml/props introduce Microsoft.DotNet.Helix.JobMonitor at a different version (11.0.0-beta.26363.117 / 11.0.0-beta.26363.117). If Version.Details.xml is intended to track the tool used by the pipeline job template, these should be aligned so dependency update automation moves them together.

    "microsoft.dotnet.helix.jobmonitor": {
      "version": "11.0.0-beta.26381.1",
      "commands": [
        "dotnet-helix-job-monitor"
      ]
    }

[Copilot]

Pull request overview

Copilot reviewed 21 out of 22 changed files in this pull request and generated no new comments.

Suppressed comments (3)

eng/pipelines/common/variables.yml:50

• enableHelixJobMonitor is set to true unconditionally, which turns on the new Helix monitor path for all runtime.yml runs immediately. The linked arcade rollout plan for HRJ/Job Monitor describes a phased rollout (including a dual-mode period). Consider defaulting this to false (or scoping it to specific pipelines/stages) so the feature can be enabled gradually and rolled back via variable override if needed.

- name: enableHelixJobMonitor
  value: true

global.json:18

• The PR description says the Helix Job Monitor dependency is the same version as Arcade, but global.json keeps Microsoft.DotNet.Arcade.Sdk at 11.0.0-beta.26365.101 while Microsoft.DotNet.Helix.Sdk is bumped to 11.0.0-beta.26381.1 (and dotnet-tools.json pins the monitor tool to 11.0.0-beta.26381.1). Please clarify whether this version skew is intentional; if not, align the Arcade SDK version with the Helix/JobMonitor build you’re taking.

  "msbuild-sdks": {
    "Microsoft.DotNet.Arcade.Sdk": "11.0.0-beta.26365.101",
    "Microsoft.DotNet.Helix.Sdk": "11.0.0-beta.26381.1",
    "Microsoft.DotNet.SharedFramework.Sdk": "11.0.0-beta.26365.101",

eng/Version.Details.xml:73

• This change also updates Microsoft.DotNet.GenAPI (version+SHA) and moves Microsoft.DotNet.Helix.Sdk’s source URI from dotnet/dotnet to dotnet/arcade. If these dependency updates are required for Helix Job Monitor enablement, it would help to call that out explicitly (or otherwise keep this PR focused by avoiding unrelated toolset churn).

    <Dependency Name="Microsoft.DotNet.Helix.Sdk" Version="11.0.0-beta.26381.1">
      <Uri>https://github.com/dotnet/arcade</Uri>
      <Sha>93eebf1a31a5eaafd44326f1a81ca107913e098c</Sha>
    </Dependency>
    <Dependency Name="Microsoft.DotNet.Helix.JobMonitor" Version="11.0.0-beta.26381.1">
      <Uri>https://github.com/dotnet/arcade</Uri>
      <Sha>93eebf1a31a5eaafd44326f1a81ca107913e098c</Sha>
    </Dependency>
    <Dependency Name="Microsoft.DotNet.GenAPI" Version="11.0.0-beta.26363.117">
      <Uri>https://github.com/dotnet/dotnet</Uri>
      <Sha>b25932e8d128b5242f1d89691f8e8171b82774c0</Sha>
    </Dependency>

[Copilot]

Pull request overview

Copilot reviewed 21 out of 22 changed files in this pull request and generated no new comments.

Suppressed comments (3)

eng/Version.Details.xml:72

• This change updates Microsoft.DotNet.GenAPI to 11.0.0-beta.26363.117 (and a different SHA) as part of the Helix/JobMonitor update. Since the PR description doesn't mention GenAPI and this appears unrelated to Helix Job Monitor enablement, it would be good to either justify why this version shift is required here or split it into a separate dependency update PR.

    <Dependency Name="Microsoft.DotNet.GenAPI" Version="11.0.0-beta.26363.117">
      <Uri>https://github.com/dotnet/dotnet</Uri>
      <Sha>b25932e8d128b5242f1d89691f8e8171b82774c0</Sha>

eng/pipelines/runtime.yml:71

• The Helix job monitor template defaults allowNoHelixJobs to false (see /eng/common/core-templates/job/helix-job-monitor.yml). Since this job is enabled here whenever enableHelixJobMonitor is true, the Build stage can legitimately produce zero Helix submissions (e.g., PRs where all Helix legs are skipped by path conditions), which would make the monitor job fail. Consider opting in to allowNoHelixJobs: true here (or gate the job on a condition that guarantees at least one Helix submission).

      - ${{ if eq(variables['enableHelixJobMonitor'], true) }}:
        - template: /eng/common/core-templates/job/helix-job-monitor.yml
          parameters:
            helixAccessToken: $(HelixApiAccessToken)
            timeoutInMinutes: 540

global.json:18

• PR description says the new Microsoft.DotNet.Helix.JobMonitor dependency is "same version as Arcade", but global.json still pins Microsoft.DotNet.Arcade.Sdk to 11.0.0-beta.26365.101 while Helix SDK/JobMonitor are 11.0.0-beta.26381.1. If the intent is version parity with Arcade, the Arcade SDK version (and any derived dependency metadata) likely needs to be updated too, or the PR description should be adjusted to match the actual versioning approach.

    "Microsoft.DotNet.Arcade.Sdk": "11.0.0-beta.26365.101",
    "Microsoft.DotNet.Helix.Sdk": "11.0.0-beta.26381.1",
    "Microsoft.DotNet.SharedFramework.Sdk": "11.0.0-beta.26365.101",

[Copilot]

Pull request overview

Copilot reviewed 21 out of 22 changed files in this pull request and generated no new comments.

Suppressed comments (2)

eng/Version.Details.props:12

• This change introduces a duplicate property. The file already defines MicrosoftDotNetHelixSdkPackageVersion later in the same PropertyGroup, so the later (older) value will win and the Helix SDK version update won’t actually take effect.

    <!-- dotnet-arcade dependencies -->
    <MicrosoftDotNetHelixJobMonitorPackageVersion>11.0.0-beta.26381.1</MicrosoftDotNetHelixJobMonitorPackageVersion>
    <MicrosoftDotNetHelixSdkPackageVersion>11.0.0-beta.26381.1</MicrosoftDotNetHelixSdkPackageVersion>
    <!-- dotnet-dotnet dependencies -->
    <MicrosoftCodeAnalysisPackageVersion>5.10.0-1.26379.102</MicrosoftCodeAnalysisPackageVersion>

eng/pipelines/runtime.yml:71

• The Helix job monitor is added unconditionally when enableHelixJobMonitor is true, but the template defaults allowNoHelixJobs=false. If a Build stage run ends up producing zero Helix jobs (e.g., path-based conditions skip all Helix legs), the monitor job may fail the stage. Consider opting into allowNoHelixJobs for runtime.yml to avoid spurious failures.

      - ${{ if eq(variables['enableHelixJobMonitor'], true) }}:
        - template: /eng/common/core-templates/job/helix-job-monitor.yml
          parameters:
            helixAccessToken: $(HelixApiAccessToken)
            timeoutInMinutes: 540

[mmitche]

/ba-g Unrelated test feailures