8.4 KiB
Void Bastion: Git- und Serververöffentlichung
Stand: 10. Oktober 2026. Diese Anleitung enthält bewusst keine Passwörter, privaten Schlüssel, Webhook-Adressen oder API-Tokens.
Zuständigkeiten
| Teil | Quelle | Ziel | Transport |
|---|---|---|---|
| Homepage und geschützte Statistikseite | outputs/void-bastion-website-git |
Gitea Emporex/Void-Bastion-Website → Netcup gergames.de/void-bastion |
Git über repositorygebundenen SSH-Deploy-Key; Netcup-Plesk-Git-Anbindung |
| Online-Spielserver/Nakama | outputs/void-bastion/server/nakama/runtime/build/index.js |
Unraid /mnt/user/appdata/void-bastion-online/nakama/modules/build/index.js |
bestehender SSH-Alias unraid-codex, tools/deploy-nakama.ps1 |
| Windows-Spiel | Godot-Projekt outputs/void-bastion |
Gitea-Release mit Setup-EXE; Homepage verlinkt neuestes Release | separater Windows-Build-/Release-Prozess |
Die Website und der Nakama-Server sind unterschiedliche Systeme. Ein Git-Push zur Website aktualisiert nicht automatisch den Heimserver. Ein Nakama-Upload aktualisiert nicht automatisch Netcup.
Website: direkt per Git arbeiten
Der aktuelle Arbeitsklon ist outputs/void-bastion-website-git. Sein origin zeigt per SSH auf Port 2202 des lokalen Unraid-Gitea. In der lokalen .git/config steht core.sshCommand mit dem repositorygebundenen Schlüssel C:/Users/Domin/.ssh/id_ed25519_void_bastion_site und der separat geprüften Host-Key-Datei known_hosts_void_bastion_gitea. Der private Schlüssel ist nicht im Repository. Der Gitea-Schlüssel hat Schreibrechte nur für Emporex/Void-Bastion-Website. Er ist auf diesem PC ohne Passphrase gespeichert und durch die Windows-Dateirechte auf Benutzer, Administratoren und System begrenzt. Ein laufender SSH-Agent ist hierfür nicht nötig. Bei Verlust des PCs den Deploy-Key in Gitea widerrufen.
cd 'C:\Users\Domin\Documents\Codex\2026-10-02\ich\outputs\void-bastion-website-git'
git pull --ff-only
git status
# Nur beabsichtigte Dateien bearbeiten und gezielt stagen, z. B.:
git add intern/statistik/index.php
git commit -m "Beschreibung der Änderung"
git push origin main
Vor jedem Push git status und git diff --cached prüfen. Keine Zugangsdaten committen. intern/statistik/stats-config.local.php bleibt ausschließlich auf dem Webhosting und ist in .gitignore ausgeschlossen.
Netcup-Plesk ist mit dem Gitea-Repository Emporex/Void-Bastion-Website, Branch main, und dem Ziel /gergames.de/void-bastion verbunden. Seit dem 10. Oktober steht der Plesk-Bereitstellungsmodus auf Automatisch. Im Gitea-Repository ist der aktive Webhook „Plesk – Void Bastion Website“ eingerichtet: nur Push-Events, Branch-Filter main, POST mit application/json. Seine Plesk-Zieladresse enthält einen Zugriffswert und darf weder in Git noch in diese Doku kopiert werden. Ein Test-Event und der echte Push von Commit 3502e04 erhielten jeweils HTTP 204. Der harmlose HTML-Kommentar dieses Commits war danach auf der öffentlichen Homepage sichtbar, ohne manuelle Plesk-Aktion. Damit reicht künftig für Website-Änderungen der geprüfte git push origin main; anschließend die betroffene Live-Seite prüfen. Die Windows-Versionsanzeige kommt separat über latest-release.php aus der Releases-API und beweist keine PHP-Bereitstellung.
Falls eine Änderung nicht live erscheint: In diesem Gitea-Repository unter Einstellungen → Webhooks die jüngste Zustellung und Antwort prüfen. In Plesk nur bei void-bastion.gergames.de den Git-Stand und das Bereitstellungsziel prüfen; notfalls dort „Jetzt Pull ausführen“ und „Jetzt bereitstellen“ manuell nutzen. Andere Domains oder das webhostingweite FTP/SSH-Konto nicht für automatische Uploads benutzen. Ein unerwünschtes Website-Update durch einen gezielten Git-Revert und erneuten Push zurücknehmen, nicht durch Änderungen an fremden Domains.
Ein künftiger Wechsel des PCs benötigt den lokalen privaten Schlüssel aus einem sicheren Backup oder einen neu ausgestellten Deploy-Key auf Gitea. Vor der ersten Verbindung den Gitea-SSH-Host-Key erneut mit dem am Server veröffentlichten Schlüssel vergleichen (derzeit ED25519-Fingerabdruck SHA256:WFM5G2yjTwTlJqF8OmBqx4N2O4/8L35vJ4Qu4zrC/J0 für [192.168.178.20]:2202). Die vollständige Verzeichnisstruktur und lokale .git/config lassen sich nicht allein aus einem Quellcode-ZIP wiederherstellen.
Nakama: prüfen und gezielt veröffentlichen
Im Godot-Projektordner:
& '.\tools\deploy-nakama.ps1'
& '.\tools\deploy-nakama.ps1' -Apply
Ohne -Apply läuft zuerst der Server-Simulationstest und dann ein SHA-256-Vergleich; es wird nichts hochgeladen. Mit -Apply lädt das Skript nur bei einer Änderung hoch, prüft den Hash, sichert die bisherige Serverdatei mit Zeitstempel, ersetzt sie, startet nur den Nakama-Container neu und wartet auf dessen healthy-Status. Bei einem Fehler nach der Aktivierung nicht blind erneut starten; zuerst Logs prüfen und bei Bedarf die gemeldete Sicherungsdatei wiederherstellen. Der Unraid-SSH-Zugang ist serverweit mächtig: Pfade und Containername im Skript nicht ohne Prüfung ändern.
Am 10. Oktober 2026 wurde für Alpha 11 das Server-Bundle mit SHA-256 b522531f8ae6c4ec12b2001db9fbee9fb47b3f48611c58aaab9a07439309d399 aktiviert. Nach dem gezielten Containerneustart meldete Nakama healthy. Das Bundle enthält die Freundesnamenssuche, automatische Online-Rundenberichte und die serverseitige Halbierung des ersten Welle-5-Boss-Schilds. Die wiederherstellbare Serverkopie liegt unter /mnt/user/appdata/void-bastion-online/nakama/modules/build/index.js.pre-20261010-201010.
Windows-Release und Homepage
Den Windows-Export mit packaging/windows/build.ps1 erstellen und die exportierte EXE vor dem Upload mit --headless --quit starten. Das Skript benötigt den Godot-Konsolenpfad und -MakeNsisExe mit der echten NSIS-Binärdatei. Auf diesem PC funktionierten Godot 4.7.2 unter C:\Users\Domin\Downloads\Godot_v4.7.2-stable_win64.exe\Godot_v4.7.2-stable_win64_console.exe und NSIS unter build\nsis-portable\nsis-3.13\Bin\makensis.exe. In der eingeschränkten Ausführungsumgebung schlug NSIS mit einem Windows-System-DLL-Ladefehler fehl; der Installer ließ sich mit derselben Build-Anweisung außerhalb der Sandbox erstellen. Produkt-, Installer- und Projektversion gemeinsam erhöhen. Das Skript gibt Größe und SHA-256 des Setups aus.
Im öffentlichen Gitea-Repository Emporex/Void-Bastion-Releases zuerst einen Entwurf für den neuen Tag erstellen, dann Void-Bastion-Setup-x64.exe anhängen. Das Release-Repository ist unabhängig vom Spiel-Quellcode-Repository: target_commitish muss daher auf dessen existierenden Branch (derzeit main) zeigen, nicht auf den Commit-SHA des Spiels. Den hochgeladenen Entwurf mit den über Git Credential Manager gespeicherten Zugangsdaten erneut herunterladen und SHA-256 vergleichen. Erst danach den Entwurf veröffentlichen. Keine Zugangsdaten oder Token in Skripte, Dateien oder Chat kopieren. Der vorhandene Gitea-Token hat write:repository, aber kein read:user; ein GET /api/v1/user kann deshalb trotz funktionierendem Release-Zugriff 403 liefern.
Die Website liest den neuesten veröffentlichten Release mit passendem EXE-Asset automatisch über https://void-bastion.gergames.de/latest-release.php; der Ingame-Updater liest die Release-Liste. .../releases/latest ist zur Alpha-Prüfung ungeeignet, da Gitea Vorabversionen dort nicht berücksichtigt. Nach jeder Veröffentlichung beide tatsächlichen Endpunkte und den öffentlichen Download testen. Alpha 12: v0.1.0-alpha.12, Spiel-Commit 39ed4c3, Website-Commit 417b2d8, Nakama-Bundle SHA-256 f99bdbc674556bfd59197d6cc1665a6db171e6ccde9c9103c19d4e9dfe99b4f7, Setup SHA-256 3309856C37B91B316ACF510911FE76F7F75C817D2BC515A43544566AFA50BA93. Nakama meldete nach dem gezielten Neustart healthy; latest-release.php zeigte Alpha 12 und der öffentliche Download stimmte bytegenau mit dem lokalen Setup überein.
Absicherung und Wiederherstellung
- Keine Zugangsschlüssel in Git, Doku, Chat oder Build-Artefakte kopieren.
- Git-Push über den Website-Deploy-Key und Server-Upload über
unraid-codexsind bewusst getrennt. - Für die Website bleiben die geschützte lokale PHP-Konfiguration und die Netcup-Git-Zuordnung auf Netcup; ein Git-Klon allein ist kein vollständiges Hosting-Backup.
- Für Nakama gehören PostgreSQL-Backups und die Server-Konfiguration in das bestehende Unraid-Backup. Das Deploy-Skript sichert nur die bisherige JavaScript-Datei, nicht die Datenbank.