Files

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:

  1. Änderungen seit dem letzten Release prüfen und einen deutschen Abschnitt für die nächste Patch-Version in CHANGELOG.md ergänzen.
  2. build_installer.ps1 ohne -NoVersionBump, -SkipGit oder -SkipPublish starten. 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.
  3. publish_gitea_release.ps1 nicht zusätzlich starten; das Build-Skript ruft es selbst auf.
  4. 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.