gregandClaude Opus 5.5
40e7372dab
`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>
79 lines
3.7 KiB
Markdown
79 lines
3.7 KiB
Markdown
# GBR Hosting game templates
|
|
|
|
Every game you can host on [GBR Hosting](https://gbrhosting.com) 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
|
|
|
|
```bash
|
|
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
|
|
```
|
|
|
|
`go run ./cmd/gbrgames inspect-image -game <id>` pulls the game's Docker image and reads what it needs
|
|
without starting the game: its user, home folder permissions, ports, tools and startup scripts. It then
|
|
checks the template against that, e.g. an image built around its own user needs `containerUser`, and a
|
|
startup command must read settings under the names the node gives them (`RCONPort` arrives as
|
|
`RCONPORT`). Boot tests run it first, so these fail in seconds. `-json` prints the facts for tooling.
|
|
|
|
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.
|