Add DotNet-HelixApi-Access variable group for runtime.yml - #133688
Merged
Merged
Conversation
Same as #133633 This can go away once dotnet/arcade#17537 lands
|
Azure Pipelines: Successfully started running 5 pipeline(s). 11 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure |
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
Apply the guarded credential import to all affected runtime wrappers or centralize the fix.
Pull request overview
Adds DotNet-HelixApi-Access credentials to the runtime build pipeline for internal, non-PR runs.
Changes:
- Conditionally imports the variable group at the
Buildstage. - Enables the standalone Helix monitor to authenticate.
File summaries
| File | Summary |
|---|---|
eng/pipelines/runtime.yml |
Adds guarded, stage-scoped Helix credentials; other affected wrappers remain uncovered. |
Review details
Suppressed comments (1)
eng/pipelines/runtime.yml:71
- This fixes the credential scope only for
runtime.yml, but the same standalone monitor is instantiated by the other internal-capable wrappers (runtime-android*.yml,runtime-ioslike*.yml,runtime-maccatalyst.yml, andruntime-wasm*.yml) without a stage-level variable group. Their submitter jobs importDotNet-HelixApi-Accessonly throughglobal-build-job.yml:83-86, while the sibling monitor passes$(HelixApiAccessToken)directly (helix-job-monitor.yml:276-278); therefore those internal non-PR runs can still discover zero private jobs and succeed becauseallowNoHelixJobsis enabled. Please apply the guarded import to all affected wrappers or centralize the fix in a shared template.
- ${{ if and(eq(variables['System.TeamProject'], 'internal'), ne(variables['Build.Reason'], 'PullRequest')) }}:
- group: DotNet-HelixApi-Access
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
lewing
approved these changes
Sep 11, 2026
Member
Author
|
/ba-g unrelated failures |
Member
Author
|
/backport to release/11.0 |
Contributor
|
Started backporting to |
Contributor
|
@akoeplinger an error occurred while backporting to |
Member
Author
|
/backport to release/11.0 |
Contributor
|
Started backporting to |
This was referenced Sep 11, 2026
Open
akoeplinger
added a commit
that referenced
this pull request
Sep 21, 2026
## Description Backport the Helix job monitor integration from main/release/11.0, including the groundwork from #129690 and #132150 and the re-enablement in #131969. Includes the subsequent fixes for empty stages (#132019), conditional monitor inclusion (#132882, #132884), parameter forwarding (#133002), performance monitoring (#132807, #133480), and internal credentials (#133633, #133688, #133885). - Use `Microsoft.DotNet.Helix.JobMonitor` version `10.0.0-beta.26461.103`, matching release/10.0's existing Arcade/VMR build. - Preserve the existing SDK, shared Arcade templates, queues, and release/10.0 job layouts. - Follow upstream enablement, except scheduled libraries outerloop runs retain release/10.0's existing warning-only reporting policy. - Leave SuperPMI's post-Helix processing unchanged. The separate perf-slow enablement in #133726 is not included. ## Customer Impact CI infrastructure only; no shipped runtime changes. Moves Helix waiting and test-result reporting into the standalone monitor for the enabled pipelines. ## Regression Not a product regression fix; backports existing CI infrastructure and its follow-up fixes. ## Testing - Validated YAML/JSON/XML configuration and preservation of unrelated settings. - Checked 43 entry pipelines, 149 forwarding sites, and 516 public/internal, PR/scheduled/manual, and normal/staging combinations, plus disabled-mode behavior. - Exercised MSBuild child-property forwarding and the pinned SDK's waiting/reporter properties, including environment-based opt-in. - Restored the monitor and verified its CLI compatibility under .NET 10. No product build or live Azure DevOps pipeline execution was performed locally. ## Risk Changes CI scheduling and result reporting, not product behavior. Uses the monitor package matching the branch's existing toolset and retains the release/10.0-specific scheduled outerloop failure policy. End-to-end Azure DevOps validation is still required. > [!NOTE] > This PR description and backport were prepared with GitHub Copilot. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: aae9b201-32a8-45eb-ae1a-db80a0ab4156
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Same as #133633
This can go away once dotnet/arcade#17537 lands