67 lines
3.3 KiB
Markdown
67 lines
3.3 KiB
Markdown
# Server deployment lifecycle
|
|
|
|
`deployment.plan.v1` gates only generic custom-command deployment execution:
|
|
Platform sends a protected `RunJobAssignmentResponse.executionInput.deployment`
|
|
when a server uses `custom-command` mode and Run executes the operator-reviewed
|
|
argv-oriented command inside its local policy.
|
|
|
|
Guided or existing-server game setup is plugin-owned. Platform dispatches the
|
|
plugin-declared lifecycle action reference, such as `actions/install.json` or a
|
|
supervised `actions/start.json` bootstrap, and may include generic deployment
|
|
context (`mode`, `profileKey`, `serverRoot`, and `createInputs`) so the plugin
|
|
action can resolve its own behavior. Platform does not create a game-specific
|
|
`serverDeploymentPlan`, and SCUM no longer requires a `deployment.scum.v1`
|
|
capability.
|
|
|
|
## Capability and policy
|
|
|
|
Run advertises normal lifecycle capabilities (`process.install`,
|
|
`process.start`, `process.stop`, `process.status`) and generic primitives such as
|
|
scoped files, logs, artifacts, dependency helpers, and custom deployment plan
|
|
execution. A Run that supports shell commands advertises its local shell policy
|
|
out of band with operator configuration. Platform must not infer shell support
|
|
from command text. Empty `shell` means argv-oriented execution.
|
|
|
|
## Plugin-owned game lifecycle
|
|
|
|
Game plugins own concrete game policy: install/update commands, app ids,
|
|
executable refs, default launch flags, stop-before-update behavior, and startup
|
|
argument construction. For SCUM, the plugin action assets own the SteamCMD flow:
|
|
stop `SCUMServer.exe` when updating, keep SteamCMD outside the server install
|
|
root, run
|
|
`steamcmd.exe +force_install_dir <serverRoot> +login anonymous +app_update 3792580 +quit`,
|
|
and start `<serverRoot>\\SCUM\\Binaries\\Win64\\SCUMServer.exe -port=<gamePort> -MaxPlayers=<maxPlayers> -log`.
|
|
|
|
Generated Run distributions carry validated plugin lifecycle assets into the
|
|
server-scoped workspace. Run materializes those assets at startup and executes
|
|
them through generic action template handling; it does not branch on game ids,
|
|
Steam app ids, SCUM executable paths, or launch flags.
|
|
|
|
## Required local preflight
|
|
|
|
Before a custom-command action, Run validates the selected protected deployment
|
|
body:
|
|
|
|
- absolute server root and working directory are allowed only where permitted by
|
|
local Run policy;
|
|
- selected shell kind and custom-command policy are enabled;
|
|
- no raw command, path, secret, socket address, or credential is emitted in a
|
|
result, diagnostic, log batch, or artifact name.
|
|
|
|
For plugin-owned actions, Run validates scoped action template paths, executable
|
|
asset refs, bounded environment variables, and lifecycle action/capability
|
|
matches. Deployment create inputs may be exposed to the action as bounded
|
|
environment variables such as `SERVER_CREATE_GAMEPORT`; protected command text is
|
|
not exposed unless the server explicitly uses custom-command mode.
|
|
|
|
## Safe progress reports
|
|
|
|
Run reports bounded progress with `percent`, `phase`, and a safe message. The
|
|
allowed phase vocabulary is `queued`, `claimed`, `preflight`, `scan`, `install`,
|
|
`configure`, `mapping`, `start`, and `health`. On failure it reports a stable
|
|
safe error code and summary, never the supplied path or command text.
|
|
|
|
Platform treats Run preflight as authoritative. It does not open a direct shell,
|
|
SSH connection, raw socket, or host filesystem to compensate for a failed
|
|
preflight.
|