You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Browse filesBrowse the repository at this point in the historyBrowse files
authored and
James
committed
Verify the .bat scripts on Windows in CI, and make them actually work
The .bat scripts have been "repaired but unverified" since the package rename.
Running them on a windows-latest runner turned out to require fixing two things
first, neither of which was the path staleness already dealt with.
1. lib\ shadows the current parser. These scripts predate the parser being
resolved from Maven. lib\ now holds only OLD parser jars that other things
still pin (gsqlparser-3.1.1.0, gudusoft.gsqlparser-3.0.2.5), and setenv.bat
put lib\ first on the classpath, so those win over anything newer:
javac -cp ".;build;lib/*;external_lib/*" ... checksyntax.java
-> error: cannot find symbol: class EOBTenantMode
EOBTenantMode is OceanBase tenant-mode support, far newer than a 3.x jar.
Same command with external_lib\ ahead of lib\ compiles and runs. setenv.bat
now orders it that way, with the reason written down.
The parser goes in external_lib\, which setenv.bat has always had on the
classpath and which the repository never actually created. It is fetched, not
vendored:
mvn dependency:copy -Dartifact=com.gudusoft:gsqlparser:4.1.6 -DoutputDirectory=external_lib
external_lib/ and /build/ are gitignored.
2. setenv.bat hardcoded JAVA_HOME to C:\Program Files\Java\jdk1.8.0_201, which
overwrote whatever the runner had set. It now keeps an existing JAVA_HOME and
only falls back to that path when none is set, so nobody has to edit this
file on a machine that already knows where its JDK is.
The new windows-bat job then runs the real thing: compile_checksyntax.bat,
assert checksyntax.class appears, run_checksyntax.bat, assert it reports
"syntax errors: 0". Each script ends with `pause`, which would block forever on
a runner with no keyboard, so their stdin is fed from NUL.
This covers one demo, not all 45, and that is a deliberate stopping point: the
scripts are generated from one template and go stale as a set, which is exactly
what happened when the demos moved directory. One canary catches that.
Every step above was reproduced locally before being written into the workflow,
including both failing classpath orders.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012qPRpoD8exYRrUmbfXXWXj
0 commit comments