Windows release tests invoke WSL bash instead of Git Bash when WSL is first on PATH

[pasmud]

Summary

On Windows systems with WSL enabled, the release-automation tests invoke an unqualified bash through spawnSync. Windows executable resolution can select C:\Windows\System32\bash.exe (WSL) before Git for Windows' Bash.

The extracted GitHub Actions shell fragments then run inside WSL, where the inherited Windows node, gh, and jq commands and the test harness' Windows-path assumptions are unavailable. This causes a large cluster of release-workflow test failures even though the same focused test passes when Git Bash is placed first on PATH.

Environment

• Current main: a8fc00984b07f10f5b607a9521c2f05aa57c5107
• Package source version: 0.1.5
• Windows 11 Pro, build 26200, x64
• Bun 1.3.13
• Git for Windows 2.51.2
• Also reproduced with Node 24.18.1 first on the Windows PATH

where.exe bash returns:

C:\Windows\System32\bash.exe
C:\Program Files\Git\usr\bin\bash.exe
C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\bash.exe

Reproduction

From sdk/typescript:

bun test --timeout 30000 ./tests-ts/release-automation.test.ts --test-name-pattern 'executes the manual release cut against all published versions'

Observed:

Expected to contain: "Release version must be greater than every published stable version."
Received: "/bin/bash: line 1: node: command not found
/bin/bash: line 1: node: command not found
/bin/bash: line 1: node: command not found
Release tags can only be cut from main."

0 pass
1 fail

The complete test suite produced 64 release-workflow failures with related symptoms such as node: command not found, gh: command not found, jq: command not found, missing mocked shell functions, and WSL paths. One additional authentication timeout was unrelated to this report.

A/B validation

Changing only Bash ordering makes the exact same test pass:

$env:PATH = 'C:\Program Files\Git\usr\bin;' + $env:PATH
bun test --timeout 30000 ./tests-ts/release-automation.test.ts --test-name-pattern 'executes the manual release cut against all published versions'

Result:

1 pass
0 fail

Root cause

tests-ts/release-automation.test.ts has multiple calls shaped like:

spawnSync("bash", ["-c", script], options)

The tests require a Bash environment compatible with the Windows executables and paths used by the harness, but they neither select Git Bash nor validate the resolved Bash implementation. With WSL's compatibility executable earlier on PATH, the child crosses into WSL instead.

Expected behavior

The Windows test suite should either select a compatible Git Bash explicitly, validate the selected Bash before executing workflow fragments, or skip the shell-execution cases when only an incompatible Bash is available. Enabling WSL should not make the repository test suite fail based on PATH ordering.

Suggested direction

A shared test helper could resolve and probe a compatible Bash once, then supply it to every workflow-shell test. On Windows the probe could require that the shell can execute the active Node binary and preserve the mocked command environment. If no compatible shell exists, these execution tests could be skipped with a clear reason while retaining the static workflow assertions.