Skip to content

Windows opencode discovery probe #3

Windows opencode discovery probe

Windows opencode discovery probe #3

name: Windows opencode discovery probe
# Manual, exploratory probe for #149 (pnpm/npm `.cmd` shim discovery on Windows).
# It answers one question deterministically: can the dashboard's discovery path
# execute a `.cmd` shim, or does it need `cmd /C`? CI runs with a full PATH, so
# it CANNOT reproduce the GUI PATH-inheritance angle — only the .cmd-execution
# mechanism, which is the part we need to confirm before fixing.
on:
workflow_dispatch:
jobs:
probe:
name: Probe .cmd shim execution
runs-on: windows-latest
steps:
- uses: actions/checkout@v5
- name: Install Rust stable
uses: dtolnay/rust-toolchain@stable
# --- Faithful probe: uses the dashboard crate's REAL tokio::process::Command
# path via run_bounded_binary, and prints raw outcomes. ---
- name: Rust probe (real discovery path on a temp .cmd)
working-directory: packages/dashboard/src-tauri
run: cargo test win_cmd_shim_execution_probe -- --ignored --nocapture
# --- Real-world reproduction: a pnpm-global opencode, exactly like #149. ---
- name: Confirm pnpm global .cmd shim layout (#149 mechanism 1)
shell: pwsh
continue-on-error: true
run: |
npm install -g pnpm
# pnpm's global bin dir is %PNPM_HOME%\bin (= %LOCALAPPDATA%\pnpm\bin),
# which is exactly the #149 layout. Configure + PATH it in-process so a
# global install actually lands, then observe where the .cmd shim goes.
$env:PNPM_HOME = "$env:LOCALAPPDATA\pnpm"
$binDir = Join-Path $env:PNPM_HOME "bin"
New-Item -ItemType Directory -Force -Path $binDir | Out-Null
$env:PATH = "$binDir;$env:PNPM_HOME;$env:PATH"
pnpm config set global-bin-dir "$binDir"
Write-Host "pnpm bin -g => $(pnpm bin -g 2>$null)"
# A tiny package with a bin is enough to reveal pnpm's shim path/casing;
# the heavy opencode-ai install is unnecessary to confirm the LOCATION.
pnpm add -g cowsay 2>&1 | Out-Host
Write-Host "--- *.cmd placed by pnpm ---"
$cmds = Get-ChildItem -Recurse -Filter "*.cmd" "$env:PNPM_HOME" -ErrorAction SilentlyContinue | Select-Object -ExpandProperty FullName
$cmds | ForEach-Object { Write-Host $_ }
# Pass one real pnpm-placed shim to the next step to launch directly.
$shim = $cmds | Select-Object -First 1
if ($shim) { "OPENCODE_SHIM=$shim" | Out-File -FilePath $env:GITHUB_ENV -Append -Encoding utf8 }
- name: Probe the real pnpm shim (direct launch)
shell: pwsh
continue-on-error: true
run: |
# A GUI launch of the dashboard would NOT have pnpm on PATH (mechanism
# 1), so the faithful question is: given the absolute pnpm shim path,
# does a direct CreateProcessW launch (identical to Rust's Command)
# succeed? If yes, hardcoding the pnpm path in the candidate list fixes
# #149 with no cmd /C wrapper needed.
$shim = $env:OPENCODE_SHIM
if (-not $shim) { Write-Host "no pnpm .cmd shim captured; skipping"; exit 0 }
Write-Host "resolved shim: $shim"
function Try-Launch($file, $arguments) {
$psi = New-Object System.Diagnostics.ProcessStartInfo
$psi.FileName = $file
$psi.Arguments = $arguments
$psi.UseShellExecute = $false # CreateProcessW path, same as Rust Command
$psi.RedirectStandardOutput = $true
$psi.RedirectStandardError = $true
try {
$p = [System.Diagnostics.Process]::Start($psi)
$out = $p.StandardOutput.ReadToEnd()
$p.WaitForExit()
return "LAUNCHED exit=$($p.ExitCode) out=$($out.Trim())"
} catch {
return "FAILED: $($_.Exception.Message)"
}
}
Write-Host "[direct] $(Try-Launch $shim '--version')"
Write-Host "[cmd /C] $(Try-Launch 'cmd.exe' "/C `"$shim`" --version")"