CI/CD und Releases
Workflows
.github/workflows/release-game.yml: Push auf den konfigurierten Releasepfad, self-hosted Build/Deploy, Python Bootstrap-Tools, Godot Windows Export, Manifest, Aktivierung, Cleanup..github/workflows/deploy-server.yml: manuell; rsync Server/Game3D, Secrets→.env, npm build, Compose config/build/up..github/workflows/build-bootstrap-tools.yml: Push/manuell; self-hosted Windows, PyInstaller, runtime_config aus Secrets, SSH/SCP Deployment.
Artefakte
Release erwartet Launcher.exe, Updater.exe, Game.exe, manifest.json und HolodeckArenaInstaller.exe. generate_manifest.py hasht Release-Dateien. Launcher-API unter src/server/api registriert und aktiviert Versionen. src/version.txt muss ein numerisches Punktformat mit 2–4 Segmenten erfüllen.
Self-hosted Runner
Linux-Runner benötigt Godot Mono 4.6.3/Exporttemplates, .NET, Python, rsync, Docker Compose und Schreibrechte auf Deploy-/Releasepfade. Windows-Runner benötigt Python/PyInstaller, SSH/SCP und Secret-Zugriff. Runnerzustand ist Teil des Builds; Versionen regelmäßig erfassen.
Deployment und Rollback
Serverdeploy ist workflow_dispatch; kein automatischer Push-Trigger. Game Release aktiviert nach Upload die neue Version. Rollback: vorhandene Manifestversion über Launcher-API aktivieren und gegebenenfalls Servercode separat auf kompatiblen Commit deployen. Client-/Backend-/Ruleset-/Replay-Kompatibilität vor Aktivierung prüfen.
Risiken
Die Solution ist bereinigt. Der aktive headless-server-Container exportiert beim Image-Build das Godot-Preset Linux Server. Offene Release-Risiken sind die parallelen Python-/Shared-Bootstrap-Pfade, fehlende allgemeine Test-Gates in den Workflows und noch nicht vollständig automatisierte End-to-End-Deployments.
Verwandt: Build, Konfiguration, Troubleshooting.