worshop work

This commit is contained in:
Frank Harris 2026-06-08 16:09:54 -05:00
parent 0d44c65ea5
commit 3829a4a83d
92 changed files with 487 additions and 110 deletions

View file

@ -1,5 +1,7 @@
# Linux Agent
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Role
`Agent_Linux/ogp_agent.pl` is the Linux execution agent for GSP. It is responsible for:
@ -84,10 +86,11 @@ The agent reads screen logs and may also copy a local log file into the game hom
The primary Workshop workflow is owned by the Panel `addonsmanager`, not the legacy `steam_workshop` RPC. For Linux servers the Panel:
1. writes `gsp_server_content/workshop_manifest.json` under the server home
2. stages `generic_steam_workshop_linux.sh` under `gsp_server_content/scripts/workshop/`
3. invokes the staged script through the authenticated `exec` RPC
2. writes a generated per-job shell script under `gsp_server_content/jobs/workshop/`
3. the generated job writes a temporary SteamCMD runscript and calls SteamCMD with `+runscript`
4. invokes the generated job script through the authenticated `exec` RPC
The staged script uses Python and SteamCMD, validates numeric Workshop IDs, keeps writes under the server home, logs to `gsp_server_content/workshop_install.log`, and supports DayZ/Arma-style `@mod` folders plus `.bikey` copying.
The generated job uses Python and SteamCMD, validates numeric Workshop IDs, keeps writes under the server home, logs to `gsp_server_content/workshop_install.log`, and supports DayZ/Arma-style `@mod` folders plus `.bikey` copying. The Linux agent does not need a permanent `generic_steam_workshop_linux.sh` file on disk.
The older `steam_workshop` XML-RPC method remains for legacy compatibility only and should not be treated as the primary customer workflow.

View file

@ -1,5 +1,7 @@
# Windows Agent
Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
## Role
`Agent-Windows/OGP64/OGP/ogp_agent.pl` is the Windows/Cygwin execution agent currently tracked in this repository. It mirrors the Linux agent as closely as practical, while using Windows-compatible paths, processes, and wrappers.
@ -164,10 +166,11 @@ Windows/Cygwin logs come from screen logs and/or local copies. Log retrieval sho
The primary Workshop workflow is owned by the Panel `addonsmanager`, not the legacy `steam_workshop` RPC. For Windows/Cygwin servers the Panel:
1. writes `gsp_server_content/workshop_manifest.json` under the server home
2. stages `generic_steam_workshop_windows_cygwin.sh` under `gsp_server_content/scripts/workshop/`
3. invokes the staged script through the authenticated `exec` RPC
2. writes a generated per-job shell script under `gsp_server_content/jobs/workshop/`
3. the generated job writes a temporary SteamCMD runscript and calls SteamCMD with `+runscript`
4. invokes the generated job script through the authenticated `exec` RPC
The staged script uses Python and SteamCMD, validates numeric Workshop IDs, keeps writes under the server home, logs to `gsp_server_content/workshop_install_windows.log`, and supports DayZ/Arma-style `@mod` folders plus `.bikey` copying.
The generated job uses Python and SteamCMD, validates numeric Workshop IDs, keeps writes under the server home, logs to `gsp_server_content/workshop_install_windows.log`, and supports DayZ/Arma-style `@mod` folders plus `.bikey` copying. The Windows agent does not need a permanent `generic_steam_workshop_windows_cygwin.sh` file on disk.
The older `steam_workshop` XML-RPC method remains for legacy compatibility only and should not be treated as the primary customer workflow.