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>
2.5 KiB
Boot-test runner setup
Boot tests run on a dedicated Gitea Actions runner labelled game-test. It deploys each changed game
with the node-agent's real deploy code, inside a Docker network that can reach the internet (Steam,
Mojang, plugin downloads) but not private networks or the host. scripts/boot-test.sh refuses to
run if that network is missing, so a half-configured runner can't boot servers on the LAN.
Everything here runs on the runner VM as root.
1. Isolated network
mkdir -p /opt/gbr-boottest
cp scripts/runner/setup-boottest-network.sh /opt/gbr-boottest/
chmod +x /opt/gbr-boottest/setup-boottest-network.sh
cp scripts/runner/gbr-boottest-network.service /etc/systemd/system/
systemctl daemon-reload
systemctl enable --now gbr-boottest-network
Check it from a throwaway container: the first command should print an IP, the second should time out.
docker run --rm --network gbr-boottest curlimages/curl -s --max-time 5 https://ifconfig.me
docker run --rm --network gbr-boottest curlimages/curl -s --max-time 5 http://192.168.1.1 || echo blocked
2. The runner
- In Gitea: gbreed-public → Settings → Actions → Runners → Create new runner, and copy the token.
- On the VM:
mkdir -p /opt/gitea-game-test-runner && cd /opt/gitea-game-test-runner
cp <repo>/scripts/runner/docker-compose.yml <repo>/scripts/runner/config.yaml .
echo "GITEA_RUNNER_REGISTRATION_TOKEN=<token>" > .env
docker compose up -d
The runner shows up as game-test in the org's runner list. It takes one job at a time; the build
runner keeps handling everything else.
3. Secrets
Games whose test.yaml maps a value under secrets are skipped until that Actions secret exists in
the org or repo, and the workflow passes it through (see the env: of the boot-test step).
| Secret | Game | What |
|---|---|---|
DRAGONWILDS_OWNER_ID |
RuneScape: Dragonwilds | A Player ID; the server won't start without one |
Housekeeping
Game images and SteamCMD downloads add up; each test removes its own container and volume. Clean up weekly (cron or a systemd timer) with:
docker container prune -f
docker image prune -af --filter "until=168h"
docker volume prune -af --filter "label!=gbr.cache"
Not docker system prune: it also deletes the gbr-boottest network whenever no container is using it,
and boot tests then refuse to run until systemctl restart gbr-boottest-network. Volumes labelled
gbr.cache are the AI builder's Steam download cache.