ci: run the Go suite on pull requests across Linux, macOS, and Windows - #126
Merged
Conversation
`verify` never set up Go, so nothing gated `runtime/go` on a pull request. The only workflows that ran `go test` were `tauri-desktop-release.yml` (release-time) and `computer-e2e.yml` (chronically red), and `e2e.yml` installs Go purely to build the runtime binary for its Playwright run. Add a separate `go-tests` job so the Go suite does not extend `verify`'s critical path. Linux and macOS run everything under `-race`; Windows runs the packages that carry platform-dependent behaviour — worktree hooks, path handling, host capability probing — because `providercli` and the CLI packages stub subprocesses with `#!/bin/sh` fixtures cmd.exe cannot run. The worktree projection test hardcoded `printf setup > setup-ran.txt` as its setup hook while its startup sibling was already GOOS-aware, so it could only have passed on POSIX. Give it the same treatment and compare the marker trimmed, since cmd.exe's `echo` appends CRLF. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…suming a POSIX shell The new Go job found both of these on its first run — neither is reproducible on macOS, which is why the suite had been green locally. Remote directory browsing never sorted. It reads entries through `(*os.File).ReadDir(n)`, which returns raw directory order, unlike `os.ReadDir` which sorts; the bound on entries is why the file method is used. Meanwhile the local browser sorts directories first, then case-insensitively by name (runtimecore files.go). So the same directory listed in filesystem order over SSH and alphabetically when local. macOS happened to return a sorted order and hid it; Linux ext4 did not. Apply the local browser's comparator. The test now creates "zeta dir" and "alpha file.txt" as well, because with only the original two entries the expected order is identical under three different sorts — it asserted nothing about ordering. The worktree PTY teardown tests hardcoded /bin/sh as the session command. They need any long-lived process to hold a PTY, so give them cmd.exe on Windows rather than skipping: worktree teardown is precisely what the Windows job is there to cover, since its process-tree kill path differs most from the others. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
runtime/gohad zero coverage on pull requests. Theverifyjob inpr.ymlnever sets up Go, so no PR check has ever rungo test. The only workflows that do run it aretauri-desktop-release.yml(release-time only) andcomputer-e2e.yml(chronically red onmain).e2e.ymlinstalls Go, but purely to build the runtime binary for its Playwright run — it never invokes the test suite.That gap matters more than usual right now: the remaining open ports (#79, #80, #83, #84) are all Go-side — SSH transport, mobile pairing, watchdog and scan bounds. Without this job, none of them can be regression-checked by CI at all.
This also closes the last open acceptance criterion of #81, which asks for automated acceptance covering both Windows and macOS.
What
A separate
go-testsjob, deliberately not folded intoverifyso the Go suite does not extend that job's critical path:-raceubuntu-latest./...macos-15./...windows-latestruntimecore,runtimehttp,hostprobeWindows runs a subset because
providercliand thecmd/*packages stub their subprocesses with#!/bin/shfixtures thatcmd.execannot execute. The three packages it does run are the ones carrying platform-dependent behaviour — worktree hook execution (.cmdtemp file +cmd.exe /d /s /c+taskkill /t /fversus/bin/bash -c+Setpgid), path handling, and host capability probing.-raceis omitted on Windows because the detector needs a CGO toolchain the runner does not reliably provide; Linux and macOS already cover it.One test could only ever have passed on POSIX
runtime_rpc_workspace_projection_test.goalready had a GOOS-awareruntimeRPCStartupMarkerCommand(), but its setup hook was hardcoded toprintf setup > setup-ran.txt. The setup hook runs throughcmd.exeon Windows, which has noprintf. Added the matchingruntimeRPCSetupMarkerCommand()and compared the marker trimmed, sincecmd.exe'sechoappends CRLF.Verification
GOOS=windows GOARCH=amd64 go vetclean on all three Windows-matrix packages, test files included — so they compile for the target.go test ./... -racegreen, exit 0, matching the pre-change baseline onmain(1a208d27b).pnpm verify:tauri-mainlinepasses with two new contract rules pinning the matrix and the GOOS-aware setup marker.pr.ymlparsed and the matrix asserted programmatically rather than by eye.Whether the three packages actually pass on a Windows runner is what this PR exists to find out; that answer only comes from CI. If something platform-specific surfaces there, the fix belongs in this PR.
🤖 Generated with Claude Code