Build und Deployment

Lokaler Build

dotnet build "src/HolodeckArena.Game3D/Holodeck Arena 3D.csproj"
dotnet build src/HolodeckArena.Shared/HolodeckArena.Shared.csproj -c Release
dotnet build src/HolodeckArena.Networking/HolodeckArena.Networking.csproj -c Release

Die Solution ist bereinigt und kann mit dotnet build HolodeckArena.sln vollstaendig gebaut werden.

Godot-Export

src/HolodeckArena.Game3D/export_presets.cfg und das Root-export_presets.cfg definieren Presets. Der Release-Workflow verwendet:

godot --headless --verbose --path src/HolodeckArena.Game3D --export-release "Windows Desktop" Game.exe

Auf dem Runner müssen Godot 4.6.3 Mono und passende Export Templates installiert sein. Lokal baut der aktive Compose-Service headless-server das Preset Linux Server reproduzierbar über src/server/headless/Dockerfile; Start und Konfiguration sind unter Headless-Server dokumentiert.

Nakama und Container

src/server/nakama/Dockerfile baut mit Node 20 und läuft auf Nakama 3.22.0:

Set-Location src/server/nakama/modules
npm ci
npm run build

Der Server-Workflow .github/workflows/deploy-server.yml wird nur manuell ausgelöst, synchronisiert Server und Game3D auf einen self-hosted Linux-Runner, schreibt .env aus GitHub-Secrets, baut TypeScript/Compose und startet den Stack.

Game Release

.github/workflows/release-game.yml baut Python-Launcher/Updater/Installer, exportiert Game3D für Windows, erzeugt mit src/tools/generate_manifest.py ein SHA-256-Manifest, veröffentlicht Dateien, registriert/aktiviert sie über src/tools/publish_latest.py und behält fünf Releases. .github/workflows/build-bootstrap-tools.yml baut Bootstrap-Tools auf self-hosted Windows und veröffentlicht per SSH/SCP.

Versionierung und Rollback

Die Release-Version stammt aus src/version.txt. Aktivierung erfolgt über die Launcher-API; ein Rollback aktiviert eine noch registrierte Version erneut. Die API hält maximal fünf Releases (MAX_LAUNCHER_RELEASES, Standard 5). Vor Rollback Manifest, Dateien und Runtime-Konfiguration prüfen.

Sicherheitsregeln

Keine Serverkeys, Tokens, Datenbank- oder Console-Passwörter in Repository, Buildlogs oder Dokumentation. Deployment-Secrets kommen aus GitHub-Secrets in die chmod-600-.env. Änderungen an safe_release_path, Manifest-Hashing, Updater-Pfaden oder SSH-Handling benötigen Bootstrap-Tests und Review.

Siehe CI/CD und Release und Troubleshooting.