Turn on Helix Job Monitor - #38751
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
@AndriySvyryd PTAL |
There was a problem hiding this comment.
Pull request overview
Enables Arcade’s Helix Job Monitor in EF Core’s public and internal Azure DevOps pipelines so Helix submission jobs can stop after queueing, while a dedicated monitor job publishes test results and drives the final Helix status.
Changes:
- Add
Microsoft.DotNet.Helix.JobMonitordependency/version plumbing and pin the tool via.config/dotnet-tools.json. - Enable Helix Job Monitor behavior in
eng/helix.projwhenSYSTEM_ACCESSTOKENis available. - Add the
helix-job-monitor.ymljob template to both public and internal pipelines.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| eng/Version.Details.xml | Adds Helix Job Monitor dependency tracking entry. |
| eng/Version.Details.props | Introduces Helix Job Monitor version properties alongside other dotnet-dotnet dependencies. |
| eng/helix.proj | Turns on Helix Job Monitor mode when SYSTEM_ACCESSTOKEN is set. |
| azure-pipelines-public.yml | Adds Helix Job Monitor job template to the public pipeline (currently with an indentation issue). |
| azure-pipelines-internal-tests.yml | Adds Helix Job Monitor job template to the internal test pipeline and passes helixAccessToken. |
| .config/dotnet-tools.json | Pins the dotnet-helix-job-monitor tool version for dotnet tool restore. |
| env: | ||
| HelixAccessToken: $(_HelixAccessToken) | ||
| SYSTEM_ACCESSTOKEN: $(System.AccessToken) | ||
| - template: /eng/common/core-templates/job/helix-job-monitor.yml |
| - template: /eng/common/core-templates/job/helix-job-monitor.yml@self | ||
| parameters: | ||
| helixAccessToken: $(HelixApiAccessToken) | ||
| - stage: validate |
There was a problem hiding this comment.
You need to change the validate logic to also check whether the corresponding Helix monitor job succeeded
There was a problem hiding this comment.
Ideally, we should check the result of each individual Helix job to preserve the validation logic, though I am not sure whether this is currently possible to do here (feature request?)
Otherwise, add $helixJobMonitorResult to each item in $groupResults instead of failing outright
There was a problem hiding this comment.
Ideally, we should check the result of each individual Helix job to preserve the validation logic
What would be the benefit of this? The helix jobs no longer depend on the test results, they just send the tests off and then report green. If one fails, the monitor will fail too
There was a problem hiding this comment.
What would be the benefit of this? The helix jobs no longer depend on the test results, they just send the tests off and then report green. If one fails, the monitor will fail too
Right, the benefit would be from checking the helix monitoring jobs for test failures specific to that leg
There was a problem hiding this comment.
the benefit would be from checking the helix monitoring jobs for test failures specific to that leg
But the individual legs don't fail when there are test failures - as soon as the tests are sent to helix, they complete w/ success. Only the helix monitor job will ever fail for test failures.
There was a problem hiding this comment.
Only the helix monitor job will ever fail for test failures.
Yes and we need to make that failure more granular, so that we can continue to check only the relevant failures in the validation groups.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Enable Arcade's Helix Job Monitor for the public and internal test pipelines. Helix submission jobs can now release their agents after queueing work, while the monitor publishes test results and owns the final Helix status.