[ci-fix] Needs review: select gen-debug-dump-docs Helix post-command shell by WindowsShell (refs #131382)

[github-actions]

Workflow artifact: ci-fix
Artifact kind: help
Linked KBE: #131382

Note

This is an AI/Copilot-generated best-effort fix attempt that I could not fully validate by running the Helix pipeline. It is a starting point for a maintainer, not a finished change. Please review the analysis below before merging.

Root cause (best analysis)

Windows Helix work items fail after their tests have already run with:

'$HELIX_PYTHONPATH' is not recognized as an internal or external command

The gen-debug-dump-docs.py post-command in src/libraries/sendtohelixhelp.proj (the BuildHelixWorkItems target) selected the cmd-style vs POSIX-style command form based on '$(TargetOS)' == 'windows':

• Windows form (%HELIX_PYTHONPATH% ...\gen-debug-dump-docs.py) — emitted when TargetOS == windows.
• POSIX form ($HELIX_PYTHONPATH .../gen-debug-dump-docs.py) — emitted when TargetOS != windows.

But the shell that actually runs the work item is chosen elsewhere in the same file by $(WindowsShell):

<WindowsShell Condition="'$(TargetOS)' == 'windows' or '$(BrowserHost)' == 'windows' or ($(TargetRuntimeIdentifier.ToLowerInvariant().StartsWith('linux-bionic')) and $(HelixTargetQueue.ToLowerInvariant().Contains('windows')))">true</WindowsShell>

So for linux-bionic (Android) — and, per @matouskozak on the KBE, MacCatalyst x64 — work items that run on a Windows Helix queue, WindowsShell is true while TargetOS is not windows. The old condition emitted the POSIX $HELIX_PYTHONPATH form into cmd.exe, which does not expand $VAR, so the post-command failed and the work item exited 1 even though the tests themselves passed. Every other shell-sensitive command in this file already keys off $(WindowsShell).

Attempted fix

Key the post-command shell selection off $(WindowsShell) instead of $(TargetOS), matching the rest of the file:

• Condition="'$(TargetOS)' == 'windows'" → Condition="'$(WindowsShell)' == 'true'"
• Condition="'$(TargetOS)' != 'windows' and ..." → Condition="'$(WindowsShell)' != 'true' and ..."

The browser/wasi exclusions on the POSIX branch are preserved.

What is unverified / where I need help

• I could not run the Helix pipeline (Android/MacCatalyst-on-Windows-queue legs) in this environment to confirm the emitted work-item command line is now the cmd form and that the post-command succeeds. A CI run on runtime-extra-platforms for those legs would confirm.
• Please confirm no other HelixPostCommands/HelixPreCommands producer for these legs relies on the old TargetOS-based split.

Validation

• Command: not run because the Helix work-item command is only materialized during a CI Helix submission, which is not reproducible in this sandbox
• Result: not run

Evidence

• Failing build: see the Build: link in [ci-scan] Build break: Windows Helix work items fail on unexpanded $HELIX_PYTHONPATH in gen-debug-dump-docs post-command #131382 (Windows Helix work items on runtime-extra-platforms).
• First build it occurred: as recorded in [ci-scan] Build break: Windows Helix work items fail on unexpanded $HELIX_PYTHONPATH in gen-debug-dump-docs post-command #131382 (computed within the scanned window; may not be the true origin).
• Suspected regressing change: none identified with sufficient confidence — this is a latent shell-selection mismatch exposed on Windows Helix queues for non-Windows target OSes.

Help wanted

• Likely author: omitted — no single high-confidence regressing PR identified.
• Area owners (area-Infrastructure): @agocke, @dotnet/runtime-infrastructure (consultant: @MichaelSimons)

Suggested reviewers / area contacts

• @matouskozak confirmed the same failure on MacCatalyst x64 jobs in the KBE and may be able to validate the mobile/Windows-queue legs.

---

Filed by ci-failure-fix. Comment here or on the workflow file to suggest changes; ci-failure-scan-feedback reads in-scope feedback daily and opens (or updates) a PR with prompt edits.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by CI Outer-Loop Failure Fixer · 426.8 AIC · ⌖ 14.7 AIC · ⊞ 17.1K · ◷

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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