Move SCUM lifecycle ownership to plugin
This commit is contained in:
npc0-hue
@@ -1,74 +1,64 @@
|
||||
# Server deployment plan v1
|
||||
# Server deployment lifecycle
|
||||
|
||||
`deployment.plan.v1` is the capability gate for Run implementations that can
|
||||
execute a protected server deployment plan. Platform only sends the plan in a
|
||||
leased `RunJobAssignmentResponse.executionInput.deployment`; it never appears
|
||||
in public server, job, audit, log, or plugin-bridge responses.
|
||||
`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.
|
||||
|
||||
SCUM controlled deployments additionally require `deployment.scum.v1`. The
|
||||
leased assignment includes `executionInput.serverDeploymentPlan` with
|
||||
`schemaVersion: "1"`, an operation of `install` or `adopt`, the frozen template
|
||||
key/version, Steam app id, logical executable/config references, explicit field
|
||||
mappings, discovery markers, and required verification checks. The plan is
|
||||
secret-free and contains logical keys only; the protected deployment body still
|
||||
holds the operator's paths/commands and is resolved only by Run.
|
||||
Guided or existing-server game setup is plugin-owned. Platform dispatches the
|
||||
plugin-declared lifecycle action reference, such as `actions/install.json`, 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 `deployment.plan.v1` along with its normal lifecycle
|
||||
capabilities. A Run that supports shell commands additionally advertises its
|
||||
local policy for `posix-sh`, `powershell`, or `cmd` out of band with its
|
||||
operator configuration. Platform must not infer shell support from command
|
||||
text. Empty `shell` means argv-oriented execution.
|
||||
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, run
|
||||
`steamcmd.exe +force_install_dir <serverRoot> +login anonymous +app_update 3792580 validate +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 write, install, or process action, Run validates the selected plan:
|
||||
Before a custom-command action, Run validates the selected protected deployment
|
||||
body:
|
||||
|
||||
- absolute server root and working directory are allowed anywhere permitted by
|
||||
the local Run policy; they are not required to be adjacent to the Run binary;
|
||||
- the effective directory, executable, permissions, timeout, plugin version,
|
||||
and requested ports are locally valid;
|
||||
- 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 an SCUM `install`, Run performs SteamCMD app installation followed by
|
||||
configuration materialization and health checks. For `adopt`, Run performs a
|
||||
scan first and must not reinstall or overwrite existing configuration. A
|
||||
controlled SCUM install or adoption requires an explicit protected server root;
|
||||
the root is never exposed in browser projections. Adoption does not require
|
||||
new-install create inputs because its mapping phase is read-only unless a
|
||||
separate approved write is dispatched. A
|
||||
terminal SCUM result must include bounded `serverDeploymentEvidence` with
|
||||
preflight, discovery, mapping, and verification states. Required mapping
|
||||
results are `applied` or `unchanged`; required verification results are
|
||||
`passed` (adoption may report mapping as `skipped`). Failed results include a stable `failureCode` and never include the
|
||||
resolved path or command text. Successful result kinds are
|
||||
`scum.install.completed` and `scum.adopt.completed`; failed result kinds are
|
||||
`scum.install.failed` and `scum.adopt.failed`.
|
||||
|
||||
The first-party Windows SCUM template declares `steamcmd`, Visual C++ 2012,
|
||||
2013, and 2015-2022 (x86 and x64), plus DirectX runtime prerequisites. Run
|
||||
checks their Windows markers before installation and uses only its fixed
|
||||
Microsoft installer catalog with silent arguments when one is absent. The
|
||||
template builds SteamCMD as separate arguments: `+force_install_dir`, the
|
||||
protected root, anonymous login, App `3792580`, `validate`, and `+quit`. The
|
||||
original root and constructed command are eligible only for opt-in local Run
|
||||
diagnostics; they never enter progress or result payloads.
|
||||
|
||||
An `existing-server` plan may omit installation. A `custom-command` plan
|
||||
requires a start command. Guided templates remain plugin recommendations;
|
||||
Run owns their local resolution and execution.
|
||||
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 such as `working-directory-unavailable`, never the supplied
|
||||
path or command text.
|
||||
`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 preflight as authoritative. It does not open a direct shell,
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user