[release/10.0] Enable Helix Job Monitor

[wtgodbe]

Carries the Helix Job Monitor forward to release/10.0 using the final design from #68007 and its follow-ups (#68472, #68561, #68706, and #68874). #68866 was the temporary disable that #68874 superseded.

• Registers Helix submissions for monitoring in all non-quarantined Helix pipelines.
• Adds one monitor job to each corresponding pipeline.
• Checks in the static tool manifest so bare monitor jobs can restore the tool.
• Uses Microsoft.DotNet.Helix.JobMonitor 10.0.0-beta.26452.107, aligned with the branch's Arcade build and including the retry/result-processing fixes.
• Leaves quarantined pipelines unchanged because their continueOnError behavior is incompatible with reporting failures from a separate monitor job.

Validation:

• dotnet tool restore
• ./eng/build.sh --restore --build --projects tools/GenerateFiles/GenerateFiles.csproj

[Copilot]

🟢 Approval recommended

The changes are consistent across pipelines, the monitor template’s restore path is supported by the newly checked-in tool manifest, and the dependency/version wiring is coherent with the pinned toolset version.

Pull request overview

Carries forward the Helix Job Monitor integration onto release/10.0 by wiring Helix submissions to be monitored and adding a dedicated monitor job to the non-quarantined Helix pipelines, with the tool pinned and restorable from a clean checkout.

Changes:

• Added Microsoft.DotNet.Helix.JobMonitor dependency metadata/version properties and pinned it to 10.0.0-beta.26452.107.
• Checked in a static .config/dotnet-tools.json (and stopped generating/ignoring it) so monitor jobs can dotnet tool restore reliably.
• Enabled monitoring in relevant Azure Pipelines by setting /p:EnableHelixJobMonitor=true and adding the helix-job-monitor.yml job template.

File summaries

File	Description
eng/Version.Details.xml	Adds the Helix Job Monitor dependency entry aligned with the branch toolset.
eng/Version.Details.props	Introduces version properties for the Helix Job Monitor package.
eng/tools/GenerateFiles/GenerateFiles.csproj	Stops generating .config/dotnet-tools.json from a template.
.gitignore	Stops ignoring .config/dotnet-tools.json now that it’s checked in.
.config/dotnet-tools.json	Pins a static tool manifest including microsoft.dotnet.helix.jobmonitor for restore in monitor jobs.
.azure/pipelines/template-tests-pr.yml	Enables monitor-aware Helix submission and adds a Helix Job Monitor job.
.azure/pipelines/identitymodel-helix-matrix.yml	Enables monitor-aware Helix submission and adds a Helix Job Monitor job.
.azure/pipelines/helix-matrix.yml	Enables monitor-aware Helix submission and adds a Helix Job Monitor job.
.azure/pipelines/ci.yml	Enables monitor-aware Helix submission (subset jobs) and adds a Helix Job Monitor job.
.azure/pipelines/ci-unofficial.yml	Enables monitor-aware Helix submission (subset jobs) and adds a Helix Job Monitor job.
.azure/pipelines/ci-public.yml	Enables monitor-aware Helix submission (subset jobs) and adds a Helix Job Monitor job.

Review details

• Files reviewed: 10/11 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[wtgodbe]

Job Monitor shows tests failing: link

But the tests tab shows no failures: link

CC @premun, @mmitche - wasn't this already fixed in main? Do we just not have a new enough Arcade (updating in #69013)?

[premun]

@wtgodbe I don't think it says "failed tests" it says "failed work item, exit code 1". It would say otherwise that it failed because of failed tests but if a work item does not even produce test results, it can still just fail. And failed work item does not get uploaded as a failed test. Or was this the case before for you?

[akoeplinger]

@premun yes looks like this was the case before, check https://dev.azure.com/dnceng-public/public/_build/results?buildId=1580019&view=results

[akoeplinger]

The underlying failure seems to be the same as #66916, looks like it's showing up on 10.0 too now. Talked with Youssef, he'll backport his fix: #69049

[premun]

I see. So I guess this is a missing feature of the HJM. I will add that behaviour: dotnet/arcade#17490

[wtgodbe]

I don't think it says "failed tests" it says "failed work item, exit code 1". It would say otherwise that it failed because of failed tests but if a work item does not even produce test results, it can still just fail. And failed work item does not get uploaded as a failed test. Or was this the case before for you?

Pre-job monitor, failed work items would always show up in the tests tab. We still want to see the output when a work item fails, so we can figure out what broke. I thought this had already been discussed and fixed in main?