Skip to content

Expand daily Windows terminal integration builder with systematic Windows chaos scenarios #38132

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
pelikhan merged 2 commits into from
Jun 9, 2026
+11 −1
Merged

Expand daily Windows terminal integration builder with systematic Windows chaos scenarios #38132

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
66d5b84
Expand Windows terminal scenario requirements
Copilot Jun 9, 2026
d32e394
Polish Windows path examples in scenario matrix
Copilot Jun 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/daily-windows-terminal-integration-builder.lock.yml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

10 changes: 10 additions & 0 deletions .github/workflows/daily-windows-terminal-integration-builder.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,8 +41,18 @@ If it is missing, create it. If it exists, improve it only when needed to match
- Build job must run on `ubuntu-latest` and compile the Windows CLI binary (`gh-aw.exe`), then upload it as an artifact.
- Integration test job must run on `windows-latest`, download the artifact, and run integration checks across several CLI commands, including help output.
- Integration tests must cover weird-but-popular Windows terminal setup combinations (for example `pwsh`, Windows PowerShell, and `cmd` execution paths) to catch shell-specific integration regressions.
- Treat scenario coverage as a systematic matrix (shell x launch mode x environment shape x path style) instead of ad-hoc spot checks.
- Include chaos-style terminal/environment scenarios that mirror common Windows developer habits:
- no-profile shells (`pwsh -NoProfile`, `powershell -NoProfile`) and default profile shells
- PATH order and PATH shadowing quirks (workspace-first, toolcache-first, duplicate entries)
- PATHEXT and extension resolution behavior for `.exe` invocation from different shells
- paths with spaces/parentheses and mixed slash styles (`C:\\path with spaces\\...` and `/` vs `\\`)
- unicode and non-ASCII working directories/user-profile-like paths
- environment toggles commonly used by developers (`NO_COLOR`, `TERM`, `CI`, and empty/minimal env subsets)
- command invocation variants (`gh-aw.exe help`, `gh-aw.exe --help`, subcommand help, and unknown-command failure paths)
- Integration test commands must defend against Windows hangs by using timeouts and clearly surfacing timeout failures.
- Include explicit checks for Windows-specific integration issues, especially command hanging behavior.
- Include at least one negative/chaos case that intentionally stresses terminal behavior and verifies failure is explicit, fast, and debuggable.
- Add a final `conclusion` job that runs with `if: always()`, aggregates prior job outcomes, and determines overall success/failure.
- If any required job fails, the conclusion job must create a GitHub issue describing failed jobs and linking the run.

Expand Down