- Python 100%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
| deploy | ||
| tests | ||
| .gitignore | ||
| action.yaml | ||
| README.md | ||
Grimstorm Build server configuration
mods.toml defines the client and server mod sets. instance.toml selects the
MCSManager target and restart timeouts. The Forgejo workflow deploys the client
payload to OrangeDB and the server payload through the MCSManager API. During
server deployment, managed JARs and existing override targets are moved into
/moddeploy/backups/<deployment-id> before staged files are moved into place.
Mod-owned data directories and other non-JAR files in mods/ are left untouched.
Override
Override files are split into three layers:
override/
├── global/
├── client/
└── server/
The effective client payload is global overlaid by client; the effective
server payload is global overlaid by server. If both layers contain the same
relative path, the environment-specific file wins.
Every UTF-8 override file is a template. Values such as ${PROJECT_ID} or
${ORANGE_DB_TOKEN} are read from the process environment at deploy time. A
referenced variable that is missing or empty stops deployment before the server
is restarted. Binary files are copied unchanged.
Client and server payloads are rendered in separate workflow steps. Server-only
secrets are exposed only to the server step and cannot be substituted into the
client payload. The workflow always provides TARGET, DEPLOY_ENVIRONMENT,
SERVER_NAME, and PROJECT_ID. Additional secrets used by server templates
must be mapped in the Build server payload step.
The override/*/mods path is reserved for mod JARs declared in mods.toml.
The override/*/moddeploy path is also reserved for deployment staging and
backups on the server.
OB Maven versions
Mods using the ob provider support explicit Maven versions and two dynamic
values:
[[mods.common]]
id = "orange-auth-mod"
provider = "ob"
project = "org.orangeboys:orange-auth-mod"
version = "latest"
latestresolves the registry's latest published version, including a snapshot.releaseresolves the registry's latest stable version. Resolution fails if the project has no stable release.
Dynamic versions are resolved on every deployment. An explicitly specified version continues to be used unchanged.