4 Commits

Include renames

Author	SHA1	Message	Date
gregandClaude Opus 5.5	f1271341ef	feat(builder): repair existing templates, a weekly check that queues repairs, and eval ... The builder could only create games; nothing noticed when a live template stopped working, and there was no way to tell whether a builder change made it better or worse. - repair -id ID: boots an existing template as nodes run it; if it fails, the same investigation as for a draft runs and the model changes only what the diagnosis says. The worker handles "repair" jobs (gameId from the panel) and opens "fix(games): repair ..." on draft/<id>; a template that boots as it is reports "nothing to repair" and opens no PR. The boot and fix loop is now shared by builds and repairs. - validate.yml runs weekly and boot-tests every game; failed games are sent to the panel (X-GBR-Event: games_boot_failed) to queue repairs. - eval -ids all: builds games that already have a template from scratch, blind, and scores each draft against it (boots, same image and app, ports, ready line, settings found) into eval.md and eval.json. - research skips our own sites, so neither research nor eval reads our templates back. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-26 00:42:34 -04:00
gregandClaude Opus 5.5	d02ed01d26	ci: stop waiting ~9 minutes on an unreachable cache ... Validate took ~10 minutes, of which ~10 seconds was work: setup-go's cache restore and save each waited ~4.7 minutes for a connect timeout, because the runners' built-in cache server sits on a network job containers can't reach. Turn off setup-go caching (three small modules aren't worth it) and the game-test runner's cache server, so any cache step skips at once. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-25 11:12:55 -04:00
gregandClaude Opus 5.5	40e7372dab	feat: inspect-image reads what a game's image needs ... `gbrgames inspect-image -game <id>` pulls the image and reads, without starting the game (probe runs with --network none and bypasses the entrypoint): its user, accounts, home folder owners and modes, tools (java, steamcmd, proton...), startup scripts and the variables they read. It then checks the template against those facts: - an image built around its own user (a locked home owned by another uid, or a declared USER) needs a matching containerUser - the startup command must read settings under the names the node gives them (the agent's toUpperSnakeCase), and must not read unset variables that have no default On the template from the first commit it reports both ARK bugs found by boot tests today (uid 25000; ${RCON_PORT} vs RCONPORT); the current five templates pass. Boot tests now run it first, so such templates fail in seconds instead of after a boot. -json prints the facts for tooling. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-25 01:42:55 -04:00
gregandClaude Opus 5.5	e9ff989246	ci: boot-test changed games before publishing ... Only games whose folder changed are boot-tested (against the previous main commit, or against main on branches; manual runs pick games). Each one is deployed by the node-agent's real deploy code on a dedicated game-test runner, in a network that can reach the internet but not the LAN. Publishing to the panel runs only if they all booted. - boottest-payload builds the DEPLOY_SERVER message the panel would send - readyPattern/failPatterns in game.yaml; readyExample in test.yaml is checked against the pattern during validation - secrets in test.yaml come from CI; a game missing one is skipped - Minecraft gets a ready pattern; Dragonwilds needs DRAGONWILDS_OWNER_ID - RUNNER.md + scripts/runner: runner, isolated network, systemd unit Also fixes newline values ("\n" separators/footers) that yaml.v3 wrote as "" on import, which would have broken ARK and Dragonwilds config files once synced, and adds a round-trip test for the importer. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-24 17:49:19 -04:00