chore(modules): declare the UO module for the UOMysticmoon instance
The module-system cutover puts a game-agnostic core on `main`, so the image UOMysticmoon deploys stops carrying any UO code of its own. Everything that instance is actually for — the shard pages, the player's characters, vendors and houses, Admin -> Shard and the uo-link connection — arrives as RunicGateway/Module-uo or does not arrive at all. Declare it in the tenant template, next to the other values that pin this instance to production, so an operator copying the file gets a working shard rather than a working site with no game on it. The compose host resolves the set itself at boot (MODULE_SYSTEM.md 2.7.2 decision 4), which is what keeps the site from being game-less between the image roll and someone clicking install in Admin -> Modules. Nothing here is new machinery: MODULES and its no-op-without-network behaviour shipped in phase 4 slice 3, MODULE_SOURCE_HOSTS already defaults to the host this URL names, and core's .env.example documents the variable and deliberately leaves it commented out. Only this instance's template is opinionated, which is the split the module system exists to make. Verified the declared manifest resolves anonymously (200, coreApi ^1.3.0 against core's MODULE_API_VERSION 1.5.0) — the container fetches it with no credentials. Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
@@ -28,3 +28,36 @@ TOTP_ISSUER=UOMysticmoon
|
||||
DB_NAME=uomysticmoon
|
||||
DB_USER=uomm
|
||||
COOKIE_NAME=uomm_token
|
||||
|
||||
# ── The UO module — REQUIRED for this instance, not optional like the vars above.
|
||||
#
|
||||
# Core is game-agnostic (docs/website/MODULE_SYSTEM.md): every shard-facing
|
||||
# surface this instance runs — the shard pages, the player's characters, vendors
|
||||
# and houses, Admin → Shard, and the uo-link connection itself — lives in
|
||||
# RunicGateway/Module-uo and reaches the deployment through this line. Without
|
||||
# it, the same image is a perfectly working site with no game on it.
|
||||
#
|
||||
# It is declared here rather than left to Admin → Modules because a compose host
|
||||
# should arrive at its own set at boot, and because this instance has a shard to
|
||||
# be down for: the panel path would leave the site game-less between the image
|
||||
# roll and someone clicking install.
|
||||
#
|
||||
# Bump the version deliberately, and read Module-uo's release notes when you do —
|
||||
# the container resolves this at every start, so changing the version here is
|
||||
# what upgrades the module. A version already unpacked is a no-op that makes no
|
||||
# network call at all.
|
||||
#
|
||||
# This owns what is ON the volume, never whether the module RUNS: disabling it in
|
||||
# Admin → Modules keeps it disabled across restarts even though its files return.
|
||||
MODULES=uo@0.3.0=https://gitea.whitlocktech.com/RunicGateway/Module-uo/releases/download/v0.3.0/module-uo-0.3.0.json
|
||||
|
||||
# Module-uo reads these as the DEFAULTS for its uo-link connection, used only
|
||||
# until Admin → Shard has been saved once — after that the encrypted DB config
|
||||
# (`uo_link_config`) is authoritative and these are ignored. Left unset here on
|
||||
# purpose: an instance that has already saved Admin → Shard keeps that config
|
||||
# across the extraction (the module's schema fragment is CREATE TABLE IF NOT
|
||||
# EXISTS, so the existing row is untouched), and setting them would suggest they
|
||||
# still decide something. Module-uo's README documents them.
|
||||
# UOLINK_BASE_URL=
|
||||
# UOLINK_WS_URL=
|
||||
# UOLINK_PROTOCOL=
|
||||
|
||||
Reference in New Issue
Block a user