diff --git a/README.md b/README.md index b72d9cd..a2e7617 100644 --- a/README.md +++ b/README.md @@ -88,6 +88,25 @@ cp .valheim/dev.json.example .valheim/dev.json clean reference project generated with all supported module tiers enabled and no added gameplay code. +## Server deployment + +Generated projects are not tied to Docker. + +Server deployment supports: + +- local filesystem destinations +- remote POSIX servers over SSH +- remote Windows servers over SSH + +Docker is optional and is used only for server lifecycle operations such as +restart, status, and logs. Use `lifecycle.type: "none"` when HeimForge should +deploy files without controlling the server process. + +Automated remote deployment requires an SSH command channel. Managed hosting +providers that expose only FTP/SFTP or a control-panel file manager can still +use HeimForge build and package outputs, but deployment and restart must be +handled through the provider's tools. + ## Licensing HeimForge source and documentation outside `template/` are licensed under diff --git a/bootstrap/model.py b/bootstrap/model.py index 0a8ed78..c1b02eb 100644 --- a/bootstrap/model.py +++ b/bootstrap/model.py @@ -449,7 +449,7 @@ def deploy_topology_lines(model: ProjectModel) -> str: if model.has_client_package: lines.append(" +-- deploy client DLLs to Windows Valheim through /mnt/c/...") if model.has_server_package: - lines.append(" +-- deploy server DLLs to the Linux/Docker dedicated server") + lines.append(" +-- deploy server DLLs to the configured local or remote server") return "\n".join(lines) diff --git a/template/README.md b/template/README.md index 39f6537..dff2be2 100644 --- a/template/README.md +++ b/template/README.md @@ -34,8 +34,8 @@ For full local validation after configuring a development Valheim installation: ./scripts/bootstrap.sh ``` -See `docs/development.md` for local Valheim paths, server deployment, SSH, -Docker lifecycle configuration, and reference maintenance. +See `docs/development.md` for local setup, server deployment, and +dependency/reference maintenance. ## Modules @@ -122,6 +122,14 @@ Deployment is explicit and metadata-driven: {{DEPLOY_SIDE_NOTES_LIST}} +Server deployment is not tied to Docker. Local filesystem destinations and +remote POSIX or Windows servers over SSH are supported. Docker is an optional +lifecycle integration for restart, status, and log operations. + +Managed hosts that expose only FTP/SFTP or a control-panel file manager require +manual deployment through the provider's tools because automated remote +deployment requires an SSH command channel. + Server deployment does not restart the server unless explicitly requested. See `docs/development.md` for local and SSH deployment configuration, diff --git a/template/docs/development.md b/template/docs/development.md index c4edb42..1655680 100644 --- a/template/docs/development.md +++ b/template/docs/development.md @@ -71,6 +71,28 @@ suite metadata -> server DeploymentPlan -> local or SSH deployment Changing transport never changes which modules enter the server plan. The local and SSH backends receive the same exact metadata-derived DLL list. +### Choosing a server setup + +Docker is optional. Deployment transport and server lifecycle are configured +independently. + +| Server environment | Deployment | Lifecycle | +| --- | --- | --- | +| Same machine or mounted filesystem | `type: "local"` | `none` or `docker` | +| Remote POSIX server with SSH | `type: "ssh"`, `remotePlatform: "posix"` | `none` or `docker` | +| Remote Windows server with OpenSSH | `type: "ssh"`, `remotePlatform: "windows"` | `none` or `docker` | +| Managed host with only FTP/SFTP or a control-panel file manager | manual/provider upload | provider-managed | + +For SSH deployment, HeimForge requires a real remote command channel in +addition to file transfer. The deployment process creates staging directories, +checks the existing deployment state, verifies files, and promotes the staged +deployment on the remote host. + +A hosting provider that exposes only FTP/SFTP or a file-management panel +therefore cannot use the automated SSH deployment backend. The generated +build/package outputs can still be uploaded through the provider's normal +tools. + ### Local transport The generated schema-v2 example uses a local suite-specific destination: diff --git a/tests/bootstrap/test_model.py b/tests/bootstrap/test_model.py index 527b836..7aac037 100644 --- a/tests/bootstrap/test_model.py +++ b/tests/bootstrap/test_model.py @@ -181,6 +181,11 @@ def test_pending_proof_lists_omit_diagnostics_line_when_absent(self): self.assertNotIn("Shared Diagnostics", tokens["HARDENING_PENDING_PROOF_LIST"]) self.assertIn("- Shared Diagnostics RPC runtime proof", token_map(build_model(make_params()))["PENDING_RUNTIME_PROOF_LIST"]) + def test_deploy_topology_is_hosting_agnostic(self): + topology = token_map(build_model(make_params()))["DEPLOY_TOPOLOGY_LINES"] + self.assertIn("configured local or remote server", topology) + self.assertNotIn("Linux/Docker", topology) + def test_deploy_side_notes_name_exactly_the_modules_that_side_receives(self): server_core_and_diagnostics = token_map( build_model(make_params(include_client=False)) diff --git a/tests/fixtures/test_no_stale_module_references.py b/tests/fixtures/test_no_stale_module_references.py index b58eaca..4e97a55 100644 --- a/tests/fixtures/test_no_stale_module_references.py +++ b/tests/fixtures/test_no_stale_module_references.py @@ -95,7 +95,7 @@ def test_operational_documents_never_name_an_omitted_module(self): self.assertNotIn("./scripts/deploy-server.sh Debug", readme_lines) self.assertEqual(set(), server_note_lines) self.assertNotIn( - "+-- deploy server DLLs to the Linux/Docker dedicated server", readme_lines + "+-- deploy server DLLs to the configured local or remote server", readme_lines ) else: self.assertIn("- ServerPack", release_lines)