ci(windows): DISABLE_FILEWATCHER env (match upstream)#8
Merged
Conversation
GitHub Windows runners occasionally cross the 3000ms timeout on timing-sensitive shell/loop tests by ~16ms. Wrap the Windows test step in nick-fields/retry@v3 with max_attempts=2 so transient jitter does not red CI. Ubuntu unaffected. Stable failures still fail on retry, so real bugs are not masked. Also bump job timeout from 30min to 45min to fit worst-case 2x test run on Windows.
Validation of the retry approach (5-run loop, 4 completed reruns) showed 0/4 pass — the flake surface is broader than the 16ms shell/loop edge case we diagnosed. Failures sampled randomly from a ~10-test pool (config-deps 30s timeouts, shell 3s, skill discovery, node server bootstrap, multiple file ops), different tests each run. Upstream OpenCode's own test.yml sets OPENCODE_EXPERIMENTAL_DISABLE_FILEWATCHER=true on Windows for the same reason. The flag already exists in our code (packages/opencode/src/flag/flag.ts:57, 13 refs); we just never wired it in CI. Match upstream's pattern. Also revert timeout-minutes 45 -> 30 (no longer needed without retry) and drop the misleading "16ms edge case" comment.
This was referenced Apr 17, 2026
7 tasks
Astro-Han
added a commit
that referenced
this pull request
Apr 27, 2026
PawWork users on their own provider keys should not silently inherit global Claude Code instructions as their PawWork baseline (issue #230, acceptance #5). Gates the fallback push behind a Runtime.isPawWork() check so the existing opt-out flag still works for plain opencode CLI users; project-level CLAUDE.md remains as compatibility (#6). The lookup also routes through Global.Path.home so OPENCODE_TEST_HOME can stub the home directory deterministically — Bun's os.homedir() is locked at process start, which would otherwise make the global Claude path untestable under Bun's test runner. Tests cover the five scenarios from acceptance #8: fresh install, project AGENTS.md, project CLAUDE.md compatibility fallback, PawWork global AGENTS.md, and the now-ignored ~/.claude/CLAUDE.md. A non-PawWork regression test guards the Runtime.isPawWork() gate so an accidental condition inversion would fail the suite.
Astro-Han
added a commit
that referenced
this pull request
Apr 27, 2026
PawWork users on their own provider keys should not silently inherit global Claude Code instructions as their PawWork baseline (issue #230, acceptance #5). Gates the fallback push behind a Runtime.isPawWork() check so the existing opt-out flag still works for plain opencode CLI users; project-level CLAUDE.md remains as compatibility (#6). The lookup also routes through Global.Path.home so OPENCODE_TEST_HOME can stub the home directory deterministically — Bun's os.homedir() is locked at process start, which would otherwise make the global Claude path untestable under Bun's test runner. Tests cover the five scenarios from acceptance #8: fresh install, project AGENTS.md, project CLAUDE.md compatibility fallback, PawWork global AGENTS.md, and the now-ignored ~/.claude/CLAUDE.md. A non-PawWork regression test guards the Runtime.isPawWork() gate so an accidental condition inversion would fail the suite.
Astro-Han
added a commit
that referenced
this pull request
Apr 27, 2026
…k mode PawWork users on their own provider keys should not silently inherit global Claude Code instructions as their PawWork baseline (issue #230, acceptance #5). Gates the global fallback push behind a Runtime.isPawWork() check so the existing opt-out flag still works for plain opencode CLI users; project-level CLAUDE.md remains as compatibility (acceptance #6) and is unaffected here. The lookup also routes through Global.Path.home so OPENCODE_TEST_HOME can stub the home directory deterministically — Bun's os.homedir() is locked at process start, which would otherwise make this code path untestable under Bun's test runner. Tests cover the five fallback scenarios from acceptance #8: fresh install, project AGENTS.md, project CLAUDE.md compatibility fallback, PawWork global AGENTS.md, and the now-ignored ~/.claude/CLAUDE.md. A non-PawWork regression test guards the Runtime.isPawWork() gate so an accidental inversion would fail the suite.
7 tasks
This was referenced May 5, 2026
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.
Summary
OPENCODE_EXPERIMENTAL_DISABLE_FILEWATCHER: trueon Windows only (matches upstream OpenCode's test.yml).timeout-minutes45 → 30 (not needed without retry).Why
The retry approach (first version of this PR) was validated with 5 reruns on the same SHA: 4/4 completed reruns FAILED. Both inner retry attempts fail each time, on DIFFERENT tests from a ~10-test pool (config-deps 30s timeouts, shell/loop 3s, skill discovery, node server bootstrap, multiple file ops). The flake surface is far broader than the initial "16ms shell/loop" hypothesis.
Upstream OpenCode hit the same problem and uses
OPENCODE_EXPERIMENTAL_DISABLE_FILEWATCHER=trueon Windows. The flag already exists in our code (packages/opencode/src/flag/flag.ts:57, 13 call sites); the fork just never wired it in CI.Related cleanup recorded in
docs/TODO.md:publish.yml(dead in fork, gated toanomalyco/opencode) +build.yml(only active for macOS arm64) into a single release workflow. Out of scope for this PR.Test plan
gh run rerun; collect 5 data points