Run the PowerShell tests in CI under 5.1 and 7

[leonarduk]

Closes #103

Why

windows/README.md (and tests/windows_pools_test.ps1's header) said the Windows pool tests are "exercised in CI" under both pwsh and powershell.exe. Nothing ran them. powershell-parse.yml parses every .ps1 but executes none, so a runtime regression, or a cmdlet or parameter that exists only in 7 (which the parse check says it can't catch), would go green.

What

• .github/workflows/powershell-tests.yml: on windows-latest, one step for shell: powershell (5.1) and one for shell: pwsh (7). Same style as powershell-parse.yml: two named steps rather than a matrix, exit $LASTEXITCODE after the script call, and the 7 step runs even if 5.1 failed (!cancelled()).
• .github/scripts/Invoke-PowerShellTests.ps1: runs every tests\*_test.ps1.
  • Glob, not a list. A new test runs without anyone editing the workflow, so tests/install_python_toolcache_test.ps1 from Stop Install-PythonToolCache.ps1 silently installing nothing over an orphaned registration #102 is covered as soon as it merges, whichever PR lands first. A glob that matches nothing is an error.
  • Child process per test. Each test runs in its own process of the step's own shell ((Get-Process -Id $PID).Path -File, as the README documents). The tests change process-wide env (PSModulePath, COMPUTERNAME, fake-gh switches), and the pools test ends without an explicit exit 0, so running them in-process could leak state between tests and report a stale $LASTEXITCODE.
  • Every test runs and reports even after one fails, and there's one log group per test.
• windows/README.md: the claim is now true. It names the workflow and says new tests are picked up automatically.

Verified locally (Windows PS 5.1.26100 and pwsh 7.6.6)

• tests/windows_pools_test.ps1 on main: exit 0, 72/72 checks, under both shells, run directly and through the runner.
• Stop Install-PythonToolCache.ps1 silently installing nothing over an orphaned registration #102's tests/install_python_toolcache_test.ps1, run from that branch: all checks pass under both shells.
• Negative check: I added two throwaway tests (exit 3, and an uncaught throw), then deleted them. The runner exited 1 under both shells, reported both failures, and still ran and passed the real test.

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: b4c74ca0-52a2-445c-9251-89554164481f

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

DeepSeek AI Code Review

1. Acceptance criteria

• Workflow runs tests under both shells: ✅ powershell-tests.yml has two named steps, shell: powershell and shell: pwsh, each with exit $LASTEXITCODE.
• Glob discovery: ✅ Invoke-PowerShellTests.ps1 uses Get-ChildItem -Filter '*_test.ps1' and throws if zero matches.
• README accuracy: ✅ windows/README.md updated to point at the new workflow and describe the glob behavior.

All three AC items are met.

2. Bugs and logic errors

• Invoke-PowerShellTests.ps1 line ~57: & $shell -NoProfile -ExecutionPolicy Bypass -File $test.FullName — $shell is (Get-Process -Id $PID).Path, which on Windows is the full path to powershell.exe/pwsh.exe. That's fine. But -ExecutionPolicy Bypass is only valid for powershell.exe; pwsh accepts it too (it's a no-op on non-Windows but the runner is Windows), so this is OK in practice. Not blocking.
• $LASTEXITCODE after & $shell ... — correct: invoking a native executable sets $LASTEXITCODE. Good.
• ::group:: / ::endgroup:: — these are GitHub Actions log commands. They work when emitted to stdout. Fine.
• if: ${{ !cancelled() }} on the pwsh step — this is the correct idiom to run even if the previous step failed (default is success()). Good.
• actions/checkout@v7 — v7 does not exist as of the current Actions marketplace (latest is v4). This will fail at workflow parse/run time with "unable to resolve action". Blocking. Should be actions/checkout@v4.
• $root computation: Split-Path -Parent (Split-Path -Parent $PSScriptRoot). $PSScriptRoot is .github/scripts, so parent is .github, parent is repo root. Correct.
• $rel = $test.FullName.Substring($root.Length + 1) — assumes $root has no trailing separator and that FullName starts with $root + '\'. Split-Path -Parent returns a path without trailing separator, so this is correct on Windows. Fine.

3. CLI and API safety

• No CLI/API changes; no new Python dependencies; no GitHub API calls added. The workflow uses permissions: contents: read, which is minimal and correct for a checkout-only job.
• No secrets referenced. Good.

4. Test coverage

• The workflow itself is the test harness; it exercises the existing tests\windows_pools_test.ps1 and will pick up Install-PythonToolCache.ps1 silently installs nothing when an orphaned per-user registration of the same version exists #101's test via glob. The "zero tests found" guard prevents a silent-green regression if the directory is renamed. Good.
• One gap worth noting: the workflow triggers only on push to main and pull_request targeting main. If the repo uses other long-lived branches, tests won't run there — but that matches powershell-parse.yml's pattern, so it's consistent, not a regression.

5. Suggested follow-up issues

• Pin actions/checkout to a real released tag (v4) across all workflows and add Dependabot for Actions.
• Consider adding a paths: filter to powershell-tests.yml so it only runs when windows/**, tests/**, or .github/scripts/** change, to save runner minutes.
• Add a smoke test that asserts Invoke-PowerShellTests.ps1 fails when the tests\ directory is empty (guards the zero-match throw).

REQUEST CHANGES — actions/checkout@v7 does not exist; the workflow will fail to resolve the action on every run. Change to actions/checkout@v4 (or whatever the current pinned version is in powershell-parse.yml).

---

Reviewed by DeepSeek via deepseek-pr-review.yml. Advisory only.

[github-actions]

GPT AI Code Review

Skipped: API key not configured

The OPENAI_API_KEY repository secret is not set.

To enable GPT reviews, add OPENAI_API_KEY as a repository secret:

1. Go to Settings > Secrets and variables > Actions in this repo.
2. Click New repository secret.
3. Name: OPENAI_API_KEY
4. Value: your GPT API key.

Once the secret is configured, re-run this workflow or push a new commit to trigger a fresh review.

REVIEW SKIPPED - API KEY NOT CONFIGURED

---

Reviewed by GPT via gpt-pr-review.yml. Advisory only.