1.6 KiB
Release-Workflow
Wenn der Benutzer „Bau den Installer und lade es auf Gitea hoch“ oder einen sinngleichen Auftrag gibt, ist immer der vollständige Release-Workflow autorisiert:
- Änderungen seit dem letzten Release prüfen und einen deutschen Abschnitt
für die nächste Patch-Version in
CHANGELOG.mdergänzen. build_installer.ps1ohne-NoVersionBump,-SkipGitoder-SkipPublishstarten. Das Skript erhöht die Patch-Version, führt Tests und Ruff aus, baut die eigenständige PyInstaller-EXE, prüft ihren Start, erstellt den Inno-Setup-Installer, committed und pusht den Quellstand und veröffentlicht den Gitea-Release.publish_gitea_release.ps1nicht zusätzlich starten; das Build-Skript ruft es selbst auf.- Abschließend den veröffentlichten Release und seine drei Assets über die öffentliche Gitea-API prüfen.
Bei Fehlern keine Prüfung überspringen und keinen fehlerhaften Build veröffentlichen. Python, PyQt6, watchdog und alle weiteren Laufzeitabhängigkeiten müssen in der EXE enthalten sein; auf dem Zielsystem darf keine Python-Installation vorausgesetzt werden.
Interner Updater
Der Client lädt ausschließlich SyncVitoSetup-<Version>.exe und die zugehörige
SHA-256-Datei aus dem neuesten stabilen öffentlichen Gitea-Release. Nach der
Verifikation startet ein abgekoppelter Wächter. Dieser wartet auf den
vollständigen Abschluss des PyInstaller-Eltern- und Kindprozesses und startet
erst danach Inno Setup. Ein direkter Austausch der laufenden EXE ist nicht
zulässig. Bootstrap- und Inno-Setup-Protokolle bleiben für die Diagnose im
lokalen Update-Verzeichnis erhalten.