Repository navigation
test: spin+ in a real VS Code against a spin e2e stack - #37
Merged
Merged
Conversation
spinbox.cliPath is a path on the machine the extension runs on, the window's (extensionKind ui), never the workspace's. A machine-scoped setting is not read from the person's settings once a window is remote: Spinbox Remote's remote.spin.cliPath, scoped the same, came back empty while VS Code reconnected a window, and the reconnect ran another spin (spin-stack/open-remote-ssh#17). Application scope is read from the person's settings in every window; the manifest test holds it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
task test:spin-remote installs the packaged VSIX and Spinbox Remote into VS Code stable, the
resolvers proposal enabled by argv.json in the person's home as a person enables it, no
Remote-SSH, and opens vscode-remote://spin+<ws>/workspace. What it asserts is what the person
sees, from VS Code's logs, the probe and the stack:
- running and stopped: Spinbox Remote activates on onResolveRemoteAuthority:spin and runs spin
code (--start), ssh-session and tunnel; the window is a spin remote; a command typed in its
terminal runs in the workspace, read back with spin exec;
- reconnect: the tunnel killed under a connected window, as a network that drops: VS Code
resolves again, the window is back within 60 s (1 s here), and its terminal is the same
shell;
- unenrolled: key_not_enrolled, resolved once and not retried, no tunnel, no terminal;
- moved, when CASES names it, after spin's task e2e:hosts:up: spin workspace move under a
connected window, the same checks as reconnect, and another host. Not run yet.
What both lanes share moves to test/lane/lane.mjs: VS Code stable, a home per case in bwrap, the
stamping spin wrapper, the logs read back. Three things the lanes did not see before:
- the lane's directory is bound into bwrap: under the /tmp it empties, VS Code saw neither the
installed extensions nor the case's spin wrapper;
- the probe is installed as any extension is, not with --extensionDevelopmentPath: that makes
the window an Extension Development Host, which VS Code closes when an extension host goes
away, so a dropped connection closed the window; it opens its terminal once the remote's
file system answers, since activated by the resolution it ran before the remote was there;
- a case ends as soon as what it claims has failed, or VS Code has exited, rather than after
six minutes.
The reconnect case found the scope of remote.spin.cliPath (open-remote-ssh#17); with it, the
lane passes 18/18 against spin's e2e stack (f15122137) in VS Code 1.146.0, and test:remote-ssh
14/14 on the shared module.
Co-Authored-By: Claude Opus 5.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
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.
This is the harness from #24's "Done when".
task test:spin-remoteinstalls the packaged VSIX and Spinbox Remote into VS Code stable and opensvscode-remote://spin+<ws>/workspaceagainst spin's e2e stack, asserting what the person sees.argv.jsonin the person's home, as a person would do it. This verifies on stable what Spinbox opens workspaces through a remote resolver of its own, so a connection's failures are ours to see and fix #24 had left "to verify".onResolveRemoteAuthority:spinand runsspin code --start, thenssh-session, thentunnel. A command typed into the window's terminal runs in the workspace, read back withspin exec. The stopped workspace ends up running.key_not_enrolledis shown, VS Code resolves once and does not retry, and no tunnel or terminal is opened.CASES=moved, after spin'stask e2e:hosts:up. Not run yet.What it found
remote.spin.cliPathandspinbox.cliPathweremachine-scoped. A remote window doesn't read amachine-scoped setting from the person's settings, so a reconnect ran whateverspinwas on the PATH and gave up. The fix is remote.spin.cliPath read in every window: application scope open-remote-ssh#17 for the resolver, and the first commit here for Spinbox./tmp, VS Code could see neither the installed extensions nor the spin wrapper. The lane's directory is now bound in.--extensionDevelopmentPathmade the window an Extension Development Host, and VS Code closes such a window when an extension host goes away. The probe is now installed as a normal extension.Verified
Against spin's e2e stack (f15122137), VS Code 1.146.0, Spinbox Remote with #17:
test:spin-remotepassed 18/18, andtest:remote-sshpassed 14/14 on the sharedtest/lane/lane.mjs.task ciis green.One caveat: after dozens of windows against the same workspace (2 GB),
spin execto it began failing, and new terminals stopped spawning. Restarting the workspace fixed it. This is consistent with what spin#1119 describes about memory, and I didn't dig further.Part of #24.
🤖 Generated with Claude Code