gregandClaude Opus 5.5
e9ff989246
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>
GBR Hosting game templates
Every game you can host on GBR Hosting is defined by a template in this repo. They're public so you can see exactly what your server runs: the Docker image, the startup command, the install script, and every default setting.
Layout
games/<id>/game.yaml the template
games/<id>/test.yaml values CI uses to boot-test it
schema/ JSON Schemas for both files
cmd/gbrgames/ validator and importer
Reading a template
| Field | What it means |
|---|---|
defaultDockerImage |
The container image your server runs in. |
defaultStartupCommand |
The command started inside that container. |
installMethod / installConfig |
How game files are installed: STEAMCMD (anonymous SteamCMD download of appId), BASH_SCRIPT (the script shown in full), or NONE (the image already contains the game). |
defaultPorts |
Ports opened for players. |
defaultConfig |
Starting value for every setting. |
configSchema |
Which settings you can edit in the panel, with their types and limits. |
configFilePath / configFileFormat |
Where settings are written in your server's files, and in what format (INI, JSON or ENV). |
backupPaths |
What's included in backups. |
Your settings vs. the defaults
When you create a server, it starts with defaultConfig. Anything you change in the panel overrides
that one setting for your server only; everything else keeps following the template. A few settings
are fixed by your plan. For example, the key named in maxPlayersConfigKey always matches your plan's
player count.
Values filled in for you
Some defaults are placeholders the panel replaces when your server starts:
| Placeholder | Becomes |
|---|---|
{SERVER_NAME} |
Your server's name. |
{PUBLIC_IP}, {PUBLIC_HOST}, {PUBLIC_PORT_n} |
The address players connect to. |
{saved:KEY} |
A value you stored under Saved Values (e.g. a password or token). |
Generated passwords
Admin and RCON passwords are never shared between servers. A setting marked x-generate is left blank
in the template, and if you leave it blank when you deploy, your server gets its own easy password like
otter-maple-42. You can see it and change it any time in your server's settings. Values under
replace are old shared defaults: a server still using one gets a fresh password the next time it starts.
Agreements
A setting marked x-consent in configSchema (a game's EULA, for example) is never accepted for you.
You tick it yourself when you deploy.
Changes
Templates are maintained by GBR Hosting. Every change is a commit here, so the history shows what changed for each game and when. Want a game added or something fixed? Open an issue.
Tooling
go run ./cmd/gbrgames validate # what CI runs on every push
go run ./cmd/gbrgames import admin-games.export.json # pull templates from GET /api/v1/admin/games
Besides the schemas, validate checks that each folder name matches its id, that referenced config
keys exist, that consents don't default to accepted, and that no credentials or private network
addresses end up in a template.