gregandClaude Opus 5.5
04967a8a16
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>
4.7 KiB
AI builder (gbrgames worker)
The panel's AI builder (Admin → Games → AI Config Generator) is run by a worker we host ourselves. The panel only keeps a queue; every result is a pull request to this repo, which CI validates and boot-tests like any other.
Panel Builder worker (gbrgames worker, Docker)
───── ─────────────────────────────────────────
admin starts a job ──► queued ◄─poll── research: web search + page reader + model
progress / log / variants ◄─post── build: first boot → draft → boot with the node-agent
"Review draft PR" → branch draft/<id>-<job> + PR as the bot ──► CI (validate + boot test)
-
Research (
gbrgames research -name N): searches the web, reads the best pages, and has the model list the server's variants (edition, image or SteamCMD app, startup, ports). Every image and Steam app is checked for real (docker manifest inspect, anonymoussteamcmd +app_info_print) before the admin sees it. -
The admin picks a variant in the panel.
-
Build (
gbrgames build -name N -variant @v.json): first boot of the image untouched (first-boot), a draft by the model (draft, rules inAUTHORING.md), then the draft is deployed with the node-agent'sBootTest, the same check CI runs. A failed boot is investigated before the model changes anything (see below).Every server the builder starts, first boots included, is deployed by the node-agent's own code, so it runs exactly as on a node. A boot passes when the server reaches its ready line, stays up for
holdSec(60 s) after it, and listens on every port the template publishes. Files the server writes anywhere but/serverand/data(the image's ownVOLUMEfolders included) are reported as lost: nodes recreate the container on every start.Steam games are downloaded once per build into a cache volume (
gbr-steamcache-<app>, labelledgbr.cache) and copied into each boot, so later boots only check the files.STEAM_CACHE=offturns it off. -
The worker pushes
games/<id>/to a branch and opens a pull request as the bot account. A draft that validates but never booted still gets a PR, titledWIP:, with what's left listed. Nothing reaches players until a person merges it and enables the game.
The builder is game-agnostic: everything about a game comes from that game's research, first boot and
boot tests. No game's name, id or code may appear in the builder's source, its rules for the model
(AUTHORING.md), the schemas or this file, and the model is never shown another game's template (its format
example is an invented server). TestBuilderIsGameAgnostic fails the build if one does.
The worker only connects out (to the panel, Gitea, the model and the search services).
Requirements
A Docker host with the isolated gbr-boottest network (RUNNER.md, step 1), so servers booted by the
builder can't reach private networks. Enough memory for the largest server it builds (the biggest need ~16 GB) and
disk for SteamCMD downloads. The image gbr-builder:latest is published by
.gitea/workflows/builder-image.yml whenever cmd/ changes on main.
Configuration
All through environment variables; nothing about where it runs lives in this repo.
| Variable | What |
|---|---|
PANEL_URL |
The panel the worker takes jobs from |
BUILDER_TOKEN |
Shared secret the panel checks on /api/v1/builder/** (same value in the panel's env) |
GITEA_TOKEN |
The bot account's token (repository read/write; the account needs Write on this repo): pushes draft branches, opens PRs as that account. Checked when the worker starts |
OLLAMA_URL |
Ollama for the model (or MODEL_PROVIDER=gemini with GEMINI_API_KEY) |
SEARXNG_URL, READER_URL |
A SearXNG instance (JSON API) and a page-to-text reader (READER_URL/<page url>) |
MODEL, POLL_INTERVAL, WORKER_NAME, WORK_DIR |
Optional: model name, poll interval (20s), name shown in the panel, work folder |
BOT_NAME |
Optional: commit author when the token can't read its own account (no read:user scope); default gbr-bot |
Running a build by hand
On any machine with Docker and the gbr-boottest network, with OLLAMA_URL, SEARXNG_URL and
READER_URL set:
go run ./cmd/gbrgames research -name "<game>" -out research.json
# pick a variant from research.json into v.json, then:
go run ./cmd/gbrgames build -name "<game>" -variant @v.json -out build.json
The draft lands in games/<id>/, first-boot reports in firstboot-out/.