e2e tests + ci + readme - #3
Merged
Merged
Conversation
Moving the plugin into its own Gradle subproject (885ff1a) put compiled classes under plugin/build/, but this script kept looking in build/ at the repository root -- where the root project, a container with no sources of its own, never writes anything. The script could not find BshDebugAgent.class and refused to run.
bsh.Interpreter's own main() catches a script's EvalError/TargetError, prints it and returns -- never a non-zero exit, so a CI caller could not tell a failing script from a successful one. Since main() itself swallows the exception, the fix has to sit above bsh.Interpreter rather than in it: BshRunner makes the same source() call main() does, but turns that same exception into exit(1).
Discussed and deliberately deferred yesterday, but only written down in Claude's own memory rather than the repo -- so it would have been lost to anyone (or any session) not carrying that memory. FUTURE_WORK.md is the actual parking lot.
Drives a real, headless VS Code (@vscode/test-electron + Mocha) against the fixture in src/test/fixtures/workspace/, starting an actual "launch" session so the test reaches BshDebugAdapterDescriptorFactory.launch() -- the one thing agent/checks/07-dap-transport.sh, which only ever attaches to a JVM it already started, cannot cover. Reuses 07's own fixture, breakpoint line and evaluate expression so both checks are provably exercising the same behaviour one layer apart, and drives stackTrace/scopes/variables/evaluate/continue through session.customRequest() since no UI is present to trigger them by clicking. Two things only running it against a real client turned up. DapChannel never sends a terminated/exited DAP event -- the JVM exiting just drops the socket -- so completion is detected via onDidTerminateDebugSession instead, the same signal descriptorFactory.ts already uses to know when to stop waiting on the child process. And making it actually headless took two tries. Electron's Ozone platform prefers a real Wayland compositor over the X11 display xvfb-run sets up whenever one is reachable, which would have put the supposedly headless test window on screen; an ELECTRON_OZONE_PLATFORM_HINT=x11 env var alone was not enough to stop it, since xvfb-run leaves WAYLAND_DISPLAY itself in place for Electron's own auto-detection to find. runTest.ts removes WAYLAND_DISPLAY from the child's environment entirely and passes --ozone-platform=x11 as a hard switch instead, leaving Electron nothing to prefer over X11 -- verified by polling `xdotool search` against the real display while the test ran. Documented in docs/FUTURE_WORK.md and editors/vscode/README.md.
FUTURE_WORK.md listed a second JDWP channel for the Maven path as unimplemented optional work, mirroring the standalone .bsh path's manual BshJavaDebugAttach wiring. Verified by hand in runIde that this was never needed: because BshMavenRunConfiguration only augments getState() before delegating to MavenRunConfiguration's own, the Debug executor already wraps the forked Maven JVM in JDWP like any other Maven run, and a breakpoint in Java code the script calls into is actually hit. DEBUGGING.md's dual-session section was scoped to BshDebugRunner only; note the Maven path's very different (free) route to the same result.
The VS Code extension just got a real end-to-end GUI test; Neovim and Eclipse still only have the manual dap-client.py coverage, which isn't a real client. Also note that there is no CI yet, even though the Gradle build and the agent checks need nothing exotic to run on a hosted runner.
Two jobs, mirroring the split agent/checks/README.md already explains: a plain ./gradlew build, and agent/checks/run-all.sh, which exercises what a Gradle test cannot arrange from inside itself (a real mvn process, a -javaagent JVM, a socket between two processes). Both run on ubuntu-latest with nothing extra installed -- mvn and python3 are already on the image. Verified locally on JDK 21 before committing: the build and all 7 checks pass. Marks the corresponding FUTURE_WORK.md item done.
editors/neovim/tests/ drives bsh-dap.lua through a real, headless nvim-dap session (nvim -l, no display server) against the same fixture, breakpoint line and evaluate expression agent/checks/07-dap-transport.sh and the VS Code test already prove work over DapChannel -- so it covers what dap-client.py cannot: bsh-dap.lua's own launch(), the jobstart spawn and the "DAP: listening" stdout watch. nvim-dap is fetched into tests/.deps/ (gitignored) pinned to a fixed commit, since this test exercises bsh-dap.lua through it rather than vendoring its code. Confirms, on the Neovim side, the same finding the VS Code test made: DapChannel never sends a terminated/exited DAP event, so both clients only learn a session ended from the socket dropping. Marks the corresponding FUTURE_WORK.md item done, and splits Eclipse's off into its own entry now that it's the only one left open.
Eclipse has no code of its own to regress -- editors/eclipse/ is a README, not a launcher, and LSP4E's generic Debug Adapter launch configuration is upstream code configured entirely through its own UI dialog. Automating it would mean standing up a second build toolchain (Tycho, a p2 target platform, SWTBot -- LSP4E ships via p2, not Maven Central) just to re-verify that LSP4E speaks DAP correctly against this agent, something 07-dap-transport.sh's dap-client.py already proves. Add a step-by-step manual checklist instead, against the same shared fixture (now duplicated at editors/eclipse/samples/script.bsh) and the same breakpoint line and evaluate expression as 07 and the VS Code/Neovim tests, including the one thing worth watching that only shows up against a real LSP4E session: what it does when DapChannel drops the socket instead of sending a terminated event.
The old title ("bsh-plugin") and opening paragraph buried the two things this
repository provides -- BeanShell language support for IntelliJ, and a debugger
that also works standalone from VS Code, Neovim and Eclipse -- under a Gradle
subproject listing. Lead with those up front, as their own headings for
larger, unmissable heading text rather than a paragraph or plain bullets, and
expand the plugin and editor sections so each stands on its own instead of
pointing elsewhere immediately.
Along the way: em dashes to match the rest of the document's typography,
trailing whitespace, a duplicated blank line, and two accuracy fixes --
Eclipse's DAP support is LSP4E's generic client, not something built into
Eclipse, and the VS Code extension only debugs, it doesn't separately "run" a
script. "IntelliJ XDebug protocol" is reworded to "native protocol" to match
the terminology the rest of the document already uses and avoid confusion
with the unrelated PHP Xdebug.
Also documents, in both CLAUDE.md files, that commits not yet pushed to a
branch's upstream are fair game to restructure -- freely split, merge or
reorder for the clearest history, distinct from the general Claude Code
default of always making a new commit instead of amending a single one.
02-maven-plugin-realm.sh runs `mvn -o` against sample poms that need build-helper-maven-plugin and maven-enforcer-plugin. On a fresh CI runner ~/.m2/repository is empty, so offline resolution fails before BeanShell ever runs, and every assertion in that check fails as "not found".
Assertions in 02-maven-plugin-realm.sh check a file already filtered by grep, so a failure only ever reports "not found" -- never the mvn output that explains why. Give assert_contains/assert_not_contains an optional 4th argument for the unfiltered file and dump its tail on failure.
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.
No description provided.