Repository navigation
fix(tests): make skills CLI tests pass on Windows - #3916
Irish-Joseph wants to merge 1 commit into
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
@Irish-Joseph is attempting to deploy a commit to the OpenClaw Foundation Team on Vercel. A member of the Team first needs to authorize it. |
|
Codex review: needs changes before merge. What this changesThis PR replaces POSIX-only skills CLI test fixtures and expectations with platform-native paths. Example: A Windows contributor runs the skills CLI tests from drive D.
Review scores
ProductKind: Test only · Worth it: Yes · Fix scope: Complete Merge readiness⛔ Needs changes before merge - 1 item remains This PR repairs a concrete Windows test failure that remains on current main, without changing CLI behavior. No blocking code findings; GitHub still reports a merge conflict. Priority: P3 Before merge
FindingsNone. Agent review detailsHow this fits togetherThe skills command tests pass mocked registry and filesystem state into real CLI command handlers, then check install destinations, metadata, lockfiles, and replacement ordering. flowchart TD
A[Test workdir fixture] --> B[Global command options]
B --> C[Skills command handlers]
D[Mock registry responses] --> C
C --> E[Filesystem and metadata operations]
E --> F[Platform-native assertions]
Technical reviewBest possible solution: Land the platform-native test repair after resolving the conflict while preserving current main’s changelog entries. Do we have a high-confidence way to reproduce the issue? Yes: current main combines platform-joined command paths with POSIX literal expectations, and the contributor reports the corresponding Windows failures and passing candidate results; no tests were run during this read-only review. Is this the best way to solve the issue? Best fix: resolve the test fixture and derive exact expectations with platform path functions; changing production paths would violate the CLI contract, while broad separator normalization would weaken assertions unnecessarily. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 0bf64843c697. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
Review metrics
LabelsLabel changes: No label changes. Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment HistoryReview history (46 earlier review cycles; latest 8 shown)
Reviewed October 14, 2026, 7:37 AM ET / 11:37 UTC (Revision 47). |
|
This pull request has been automatically marked as stale due to inactivity. |
What Problem This Solves
Fixes: 28 of 93
packages/clawhub/src/cli/commands/skills.test.tstests fail on Windows (0 failures on Linux), which blocks Windows-based contributors from getting a green CLI test baseline.User Impact
No user-visible change. Contributors on Windows can run the skills install/update test suite and see the real pass/fail state instead of 28 spurious failures.
Why This Change Was Made
The tests inject the POSIX literal workdir
/work(via the sharedmakeGlobalOptsdefault) and assert against POSIX literals like/work/skills/html. On Windows the implementation correctly joins onto the platform rendering of that workdir, so every path assertion mismatched (\work\skills\htmlvs/work/skills/html). The real CLI never passes an unresolved literal —resolveWorkdir()always returns a platform-resolved absolute path — so the test-side fix is to model that: the workdir is now derived withresolve("/work")and all expectations are built from the same platform path via a smallworkPath()helper. Temp/backup-directory matchers accept either separator. Linux behavior is unchanged by construction: on POSIX,resolve("/work")is/workandjoin("/work", …)reproduces the old literals byte-for-byte. Implementation code is untouched.Evidence
main):skills.test.ts→ 65 passed / 28 failed, e.g.expected "writeSkillOrigin" to be called with '/work/skills/html'… received'\work\skills\html'.packages/clawhubsource suite on this host: 81 failed / 380 passed vs 109 failed / 352 passed on unmodifiedmain— the delta is exactly the 28 repaired tests; the remaining per-file failure set is byte-identical tomain(pre-existing Windows-environment failures that spawn realnpm/bun, which pass on Linux CI).Real behavior: built-CLI install / force-reinstall / update on Windows
The corrected assertions document where install/update write on a platform-resolved workdir; the same code paths run through the real built CLI (v0.24.0, this branch's head) on this Windows host against the public registry, into a scratch workdir:
Resulting on-disk state (real Windows paths, owner-scoped directory):
.clawhub\lock.json:{ "version": 1, "skills": { "@steipete/github": { "version": "1.0.0", "installedAt": 1791258547733, "ownerHandle": "steipete" } } }.clawhub\origin.json:{ "version": 1, "registry": "https://clawhub.ai", "slug": "github", "ownerHandle": "steipete", "installedVersion": "1.0.0", "installedAt": 1791258547733, "fingerprint": "6a19a2b0…" }Staging-swap path (the backup/rename flow the tests assert) via
--forcereinstall of the existing install:(no leftover
.backup-*directory; clean swap) and the update flow:bun run ci:staticpasses;tsc -p packages/clawhub --noEmit,oxlint --type-aware,oxfmt --checkclean.