Draft
Conversation
RFC proposing a cheap Phase-1 smoke CI to catch the recurring "works on Linux/macOS, breaks on Windows" bug pattern before merge. Builds on the root-cause fix in garrytan#1024 (v0.18.0.1) — that PR made CI failures loud; this RFC makes the right code paths actually run. Phase 1 (this deliverable): windows-smoke.yml that builds binaries, asserts .exe layout, smoke-tests each compiled binary, runs four Windows-specific unit tests plus a make-pdf render smoke. Phase 2 (follow-on): broader unit test subset, gated on triaging 7 pre-existing Windows-flaky tests. Phase 3 (unowned, flagged only): E2E + make-pdf-gate on Windows, gated on widening pdftotext.normalize() to handle Xpdf / Poppler- Windows output divergences. Draft for discussion. One open question: gate or continue-on-error for the first 2 weeks. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Implements the Phase 1 workflow proposed in docs/designs/WINDOWS_CI.md.
Triggers:
- pull_request against main (paths: browse, make-pdf, design, scripts,
bin, package.json, bun.lockb, self)
- push to main (same paths)
- workflow_dispatch
Steps:
1. bun install --frozen-lockfile
2. bun run build
3. Assert .exe layout (browse, find-browse, pdf, design) + server-node.mjs
4. Smoke-test binaries via --version
5. Windows-specific unit tests (4 files)
6. make-pdf render smoke
Includes a concurrency group so rapid repush on the same PR doesn't stack
runs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…--version semantics; layout check suffices)
…werShell exit-code handling
…laims with live CI data
This was referenced Apr 21, 2026
|
The focused smoke-test philosophy is pragmatic — it avoids the trap of trying to make every test pass on Windows before shipping anything. The path filter coverage looks solid for the primary Windows-compatibility culprits. One thing I noticed: |
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
2 participants
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.
Boiling the Windows CI Lake
Status: Draft for discussion. Not a merge request yet — direction confirm first.
What's in this PR
Three files:
docs/designs/WINDOWS_CI.md— the RFC itself. Full problem statement, phased rollout, goals/non-goals, receipts. (rendered view).github/workflows/windows-smoke.yml— Phase 1 of the RFC. ~95 lines. Builds onwindows-latest(free for public repos under GitHub's Jan 2026 pricing), asserts.exelayout, runs 5 Windows-sensitive unit-test files + a make-pdf render smoke.browse/test/home-dir-resolution.test.ts— a regression test for the fix(browse,design): resolve ~/.gstack via os.homedir() on Windows #1120 home-directory-fallback class of bug, included because without it the Phase 1 coverage table has a ❌ row.TL;DR
gstack ships Windows bugs that no CI job ever sees, because no workflow runs on Windows. Five instances of this pattern have been filed in the last month (one merged in #1024, four open from me in the last 24 hours: #1118, #1119, #1120, #1121). This RFC proposes a phased rollout, starting with a cheap smoke CI that would have surfaced all five at PR time.
It builds on the root-cause fix in #1024 (v0.18.0.1) — that PR made CI failures loud; this RFC makes the right code paths actually run.
Receipts
Phase 1 is not a proposal — it's already running on scarson/gstack. Every row of the RFC's coverage table has a live CI run link.
chmodno-opUnder 1:15 wall clock on GitHub-hosted
windows-latestwith a cold runner — well under the 3-5 min estimate in the original RFC draft. Cost: $0 (public repo).Why the title
From gstack's "Boil the Lake" ethos: always do the complete thing when AI makes the marginal cost near-zero. The complete thing here isn't "propose a workflow" — it's "ship a workflow that demonstrably catches every recent Windows regression, against live CI receipts." That's what this PR is.
The one open question
Gate or continue-on-error for the first 2 weeks? My default:
continue-on-error: true, report failures in the PR Checks tab, flip to gating after a clean-signal review. This is the one judgment call I don't want to make unilaterally — you have better context on gstack's flake-tolerance norms. See the RFC §"Open question for @garrytan" for reasoning.Everything else (runner sourcing, scope of the YAML, Phase 2 skip-list ownership, tier-vocabulary placement) is proposed with a defensible default in the RFC body. Push back inline on any of them if they land wrong.
Sequencing
This PR assumes #1118 / #1119 / #1121 merge first — those add the test files this workflow invokes. If you'd prefer to sequence differently, say so; the workflow's test list is straightforward to narrow.
What this PR does NOT do
pdftotext.normalize()to handle Xpdf/Poppler-Windows output. Not volunteered work on my end.make-pdf-gate.yml:26. That's its own work.🤖 Generated with Claude Code