5 Commits

Include renames

Author	SHA1	Message	Date
gregandClaude Opus 5.5	87dfca1285	feat(boot-test): test.yaml unboundPorts for ports opened only when a player connects ... The first real run of the port check found that the crossplay Minecraft server opens no UDP socket at startup: Bedrock goes through Geyser's NetherNet transport, and 19132/udp is not open after boot. It is listed as unboundPorts in that game's test.yaml, with the reason, until a Bedrock client confirms how players reach it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-26 00:05:37 -04:00
gregandClaude Opus 5.5	04967a8a16	feat(builder): every boot through the node-agent, every lost file counted, Steam cache ... What a builder boot sees is now what a node does: - First boots (untouched, or -as-deployed with exactly a new server's settings) are deployed by the node-agent's BootTest in keep mode; the builder only watches the console and inspects what's left. The Go copy of the deploy (its own docker run, mounts and startup prefix) is gone. It had drifted: it gave the image's VOLUME folders their own volumes, which nodes don't, so saves there looked safe while every start loses them. - Files written outside /server and /data are counted whatever their type (it only counted config-like extensions, so .sav or .db saves went unseen), including the image's VOLUME folders; logs, pid and lock files and system folders are left out. - Boot tests ask the server to stay up holdSec (60 s, test.yaml can set it) after its ready line and to listen on every published container port (needs the node-agent's matching BootTest). - Steam apps are downloaded once per build into a gbr.cache volume and copied into each boot, so later boots only check the files (STEAM_CACHE=off). - RUNNER.md no longer suggests docker system prune, which deletes the gbr-boottest network when nothing is using it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-26 00:00:50 -04:00
gregandClaude Opus 5.5	fe790ad223	fix(boot-test): run every boot test with exactly what a new server gets ... CI's boot test gave every blank password-like setting a throwaway value. A real deploy only fills x-generate fields, so a template whose server won't start without one passed CI and failed for the first owner who deployed it. boottest-payload now fills only x-generate fields, for CI and the builder alike. The old behaviour is kept as -fill-blank-passwords, used only by the builder's second boot to tell whether an empty setting is why a draft fails. Messages and AUTHORING.md no longer say boot tests fill passwords; a server that needs a join password gets x-generate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-25 22:01:16 -04:00
gregandClaude Opus 5.5	72a4280d44	fix(builder): boot drafts with the settings a new server really gets ... The builder's boot test filled every blank password-like setting with a throwaway value. A real deploy only fills x-generate fields, so a draft whose server refuses to run with an empty join password passed the builder and CI, and then shut down on its first real deploy. The builder now boots drafts with boottest-payload -as-deployed: only x-generate fields are filled, everything else exactly as the template's defaults. A server that won't run with its own defaults fails the build, and the model is told that empty settings stay empty, so the value must come from a default or x-generate. CI's boot test is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-25 21:14:17 -04:00
gregandClaude Opus 5.5	944b5fdd3e	fix(boot-test): never overwrite non-password settings ... The payload builder filled anything matching the validator's broad credential pattern that wasn't a non-empty string, so RCON_PORT, ENABLE_RCON and ARK's RCONEnabled/RCONPort became 'boot-123456' in the first runner run. Only fill keys named like passwords (or x-generate), and only when missing or an empty string. Adds a test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-24 21:33:29 -04:00