3 Commits

Include renames

Author	SHA1	Message	Date
James Dansereau	3dcceaafd9	ci: route windows-build to self-hosted runner (G2); land ROM-gated sweep workflow (G1) (#65) ... * ci: route windows-build to self-hosted runner (G2); land ROM-gated sweep workflow (G1) G2: windows-build now runs on the self-hosted box (corpyvt6agent01) for push/workflow_dispatch, using local ccache instead of the actions/cache round-trip and skipping msys2/setup-msys2's install once packages are already present. pull_request always stays on windows-latest — fork PRs must never reach a box that will hold a ROM. G1: adds .github/workflows/selfhosted.yml, a dispatch-only workflow that builds + runs the 21-level headless sweep (tools_pc/verify.sh sweep --json) against a runner-cached ROM. Inert until manually dispatched. Still pending (manual, physical steps on the box — not done by this commit, see docs/dev/notes/SELFHOSTED-RUNNER-PLAN.md rollout table): - register corpyvt6agent01 as a runner against this repo - confirm MSYS2 at C:\msys64 with the required mingw64 package set - one-time ROM seed into {runner_home}/_rom-seed/ - first workflow_dispatch sweep + parity check against a local run - flip G1 from workflow_dispatch to push:[main] once green Claude-Session: https://claude.ai/code/session_01J5PZ3sTHiuW6MdQnepasSU * fix(selfhosted.yml): remove invalid concurrency.max-parallel key Found by testing: dispatching the workflow failed with a hard parse error (HTTP 422, "Unexpected value 'max-parallel'"). GitHub Actions' workflow-level `concurrency` block only supports `group` and `cancel-in-progress` — `max-parallel` is a job `strategy:` key for matrix jobs, not a concurrency-block key. Serialization was already achieved via group + cancel-in-progress:false; the stray key just blocked every dispatch. Claude-Session: https://claude.ai/code/session_01J5PZ3sTHiuW6MdQnepasSU * fix(selfhosted.yml): register the msys2 shell wrapper (setup-msys2 step) Found by testing: the first fixed dispatch failed every msys2-shell step with "msys2: command not found". Unlike ci.yml's windows-build, this workflow used `shell: msys2 {0}` without ever running msys2/setup-msys2, which is what registers that shell alias for the runner — MSYS2 being pre-installed on the box doesn't help if Actions doesn't know the shell exists. Adds the same setup-msys2 step ci.yml uses, with update:false since the packages are expected already present (fast no-op per plan). Claude-Session: https://claude.ai/code/session_01J5PZ3sTHiuW6MdQnepasSU * ci: stop reinstalling MSYS2 per run on the self-hosted box The self-hosted paths (selfhosted.yml; ci.yml windows-build's push/ dispatch route) no longer call msys2/setup-msys2 or pacman -S at all. MSYS2 + the mingw64 package set are now assumed hand-maintained on corpyvt6agent01 (docs/dev/notes/SELFHOSTED-RUNNER-PLAN.md), invoked by calling its bash directly (`C:\msys64\usr\bin\bash.exe -leo pipefail "{0}"`, the same invocation setup-msys2's generated wrapper uses) with MSYSTEM=MINGW64 so /etc/profile still puts mingw64/bin on PATH. Adds tools_pc/check-selfhosted-deps.sh: a fast, install-free check that exits 0 immediately when the required packages (toolchain, cmake, SDL2, zlib, python, ccache, zip, unzip) are present, or fails with the exact `pacman -S --needed ...` line to run otherwise — so a missing package on the box surfaces immediately with a clear fix, instead of as a confusing failure deeper in the build. ci.yml's windows-latest (PR) path is unchanged: ephemeral runners still get a full msys2/setup-msys2 install every time, since there's nothing to persist there. Claude-Session: https://claude.ai/code/session_01J5PZ3sTHiuW6MdQnepasSU * fix: use msys2/setup-msys2 release:false instead of a raw bash-path shell The previous attempt (invoking C:\msys64\usr\bin\bash.exe directly as a custom `shell:` command) failed on the actual runner with "Second path fragment must not be a drive or UNC name" — a real limitation, not a typo; it failed identically in both files, including the one with a static (non-templated) shell string, so it wasn't the ${{ }} expression either. Root-caused by reading msys2/setup-msys2's actual source: `release: false` makes it reuse the existing C:\msys64 as-is (hardcoded path in that branch, confirmed in main.js) instead of downloading+installing a fresh copy, and — verified in the same source — omitting `update` and `install` skips every pacman call entirely (just one `uname -a` + a pacman.conf sed tweak, no network). This is the officially documented mechanism for self-hosted runners with a pre-existing MSYS2 install (see the action's README, "release" section). ci.yml's windows-build now runs setup-msys2 unconditionally but with release/update/install all keyed off github.event_name: full install on windows-latest (PR, ephemeral), reuse-only on the self-hosted box (push/dispatch). selfhosted.yml always uses release:false. Both then run tools_pc/check-selfhosted-deps.sh to verify the box's hand- maintained packages are actually present. Claude-Session: https://claude.ai/code/session_01J5PZ3sTHiuW6MdQnepasSU * fix(selfhosted.yml): cp -r for the ROM sidecar directories Found by testing with the ROM seed actually in place: pcmodels-ntsc-final and pccg-ntsc-final are directories (not single files, unlike ge007.ntsc-final.z64), so a plain `cp` failed with "omitting directory" and left the seed step failing on every run even with the seed populated. Claude-Session: https://claude.ai/code/session_01J5PZ3sTHiuW6MdQnepasSU * ci: drive MSYS2 MINGW64 directly via ci-shell.cmd, drop msys2 shell shim The self-hosted runs were dying with 'msys2: command not found' because the msys2/setup-msys2 action's shell shim was never registered on the box. Replace the dependency on that shim with a small committed launcher (tools_pc/ci-shell.cmd) that headlessly reproduces the local 'MSYS2 MINGW64' terminal: - MSYSTEM=MINGW64 + /mingw64/bin on PATH - NON-login bash, so it keeps the workspace cwd (a login shell cd's to $HOME and would break every relative path in the workflow) - -e -o pipefail for GitHub-style error propagation Both workflows now set defaults.run.shell to C:\msys64\ci-shell.cmd {0}; a bootstrap step (shell: cmd) refreshes the launcher from the repo into C:\msys64 each run. selfhosted.yml drops setup-msys2 entirely; ci.yml keeps it only for the ephemeral windows-latest PR path (which installs MSYS2 at C:\msys64). .gitattributes: force CRLF for *.cmd so cmd.exe parses the launcher correctly. * Revert "ci: drive MSYS2 MINGW64 directly via ci-shell.cmd, drop msys2 shell shim" This reverts commit a976b2589c. * docs(D244): log self-hosted-runner link failure — undefined reference to objectiveGetStatus_WEAK First real build attempt on the reinstalled corpyvt6agent01 box (run 34707798707) fails at link with an unresolved #pragma weak alias. A local repro of the identical alias pattern links fine on current MSYS2 (gcc 16.2.0/binutils 2.47); the box reports gcc 16.1.0 — likely a stale toolchain, consistent with rollout step 2's earlier package-hygiene gap. Claude-Session: https://claude.ai/code/session_01CUFSnpgrAyQSDVHoQQ6Sx3 * fix(verify.sh): surface run.log tail on NO-FRAMES instead of silently discarding it sweep mode's per-level run.log (the game process's own stdout/stderr, where an SDL/GL init failure would show up) was captured into a mktemp capdir but unconditionally rm -rf'd with no diagnostic ever printed for the NO-FRAMES (no-crash) case -- every level failed this way on the self-hosted runner's first real sweep attempt with zero clue why. Claude-Session: https://claude.ai/code/session_01CUFSnpgrAyQSDVHoQQ6Sx3 * fix(selfhosted.yml): stop deleting the ROM seed dir -- cache save silently fails on this box actions/cache/save has been failing to persist the ROM cache entry on corpyvt6agent01 (WARNING annotation, tar.exe exit code 2) but doesn't fail the step -- by design, a cache-save failure is non-fatal, so the workflow carried on and the now-unconditional "Delete one-time seed dir" step wiped the only copy of the ROM every single run. Every dispatch since has failed at "Seed ROM cache" with an empty seed dir and an empty cache -- exactly the user-reported "it wipes out the ROM data each run". Fix: don't delete the seed dir. It's cheap disk (three files, a few hundred MB) and the existing restore-then-seed-if-missing logic already treats it as the fallback source whenever the cache comes back empty, so leaving it in place is safe and makes the workflow tolerant of the cache-save bug until that's root-caused separately. Claude-Session: https://claude.ai/code/session_01CUFSnpgrAyQSDVHoQQ6Sx3 * fix(verify.sh): sweep --json never actually produced a verdict array; fix NO-FRAMES diagnostic clipping it further Two bugs, found together while chasing the self-hosted runner's first real sweep attempt: 1. sweep mode's `out=$(verify_level ...); echo "$out" | head -1` always discarded emit_verdict's second (--json) output line -- RESULTS_JSON was declared for assembling a verdict array but never populated or printed, so `sweep --json` has never produced anything but `[]` for the workflow's "Extract JSON verdict" step. Now builds and prints a real `[{...}, {...}]` array before the RC exit. 2. My own D244-session addition (printing a NO-FRAMES level's run.log tail) wrote to stdout, which the same `out=$(...)/head -1` capture turned into the *new* first line, clipping the real verdict summary. Moved to stderr, which bypasses that capture. Claude-Session: https://claude.ai/code/session_01CUFSnpgrAyQSDVHoQQ6Sx3 * docs: regenerate findings-index.csv for D244 Claude-Session: https://claude.ai/code/session_01CUFSnpgrAyQSDVHoQQ6Sx3	2026-09-12 15:33:07 -04:00
James Dansereau	14adbd3cad	tools_pc/verify.sh: kill each level as soon as its last GE_PCDUMP frame lands ... run_one always idled out the full watchdog (45s/level sweep, 90s/level single) even though the game only needs to render its intro pan + spawn-in once -- everything after the last requested frame was wasted wall-clock. Poll for the last frame's PPM (or a crash log) every 0.2s and kill immediately; the watchdog stays as the hang/load-flake safety net for a level that never gets there. Also trims the pre-launch settle 1s -> 0.3s. Falls back to the old timeout-wrapped launch if the --dump spec doesn't parse as lo-hi[:step] integers. Measured: bunker1 (9 frames, 80-400:40) 45s -> 18s; dam (3 frames, default 200-440:120) 90s -> 17s. A full 21-level sweep should drop from ~16 min toward ~6 min. Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG	2026-09-10 23:05:22 -04:00
James Dansereau	884cfdb9b7	tools(verify): add verify.sh + crash_brief.py (speed-ups plan Step 2, 9) ... verify.sh wraps the manual render-verify recipe (build-if-stale, 640x480 ini pin/restore, headless GE_PCDUMP capture, pixcount, framediff, crash symbolication) into one command with a machine-readable PASS/CRASH/ NO-FRAMES/REGRESSION verdict + --json, for a single level or a sweep subset. Live-tested on Windows: single-level and subset-sweep runs both produce correct verdicts and leave the tree clean. crash_brief.py turns a ge007.crash.log into a symbolicated, dispatch-ready investigation brief: greps porting-notes.md/findings-index.csv for sections covering the crashing function/file, and flags known parked-crash signatures (D188 va_list, D189 stack overrun) so agents stop re-investigating them. verify.sh calls it automatically on a CRASH verdict. Live-tested against a synthetic-but-real crash log built from an actual built symbol; caught and fixed 3 bugs before trusting it (addr2line unresolvable under native Windows Python's PATH handling, a substring keyword-match false-positive, a Windows drive-letter path-split bug). Claude-Session: https://claude.ai/code/session_01P3WrUHAFQZUuhrHhiJgTUr	2026-09-04 22:09:58 -04:00