meldestelle/docs/99_Journal/2026-05-06_Windows_Cross_Packaging_Conveyor.md

Journal-Eintrag: 06.05.2026 - Windows Cross-Packaging mit Conveyor

Kontext

Der Windows-Build (.msi) war bisher blockiert, da unser Gitea-Runner ("Zora") auf ARM64-Linux läuft und das Standard-Compose-Plugin zwingend eine Windows-Umgebung mit WiX Toolset für MSI-Pakete benötigt. Dies führte zu ständigen "Roten Kreuzen" in der CI.

Durchgeführte Arbeiten

1. 🏗️ Strategiewechsel: Hydraulic Conveyor

Anstatt auf einen Windows-Runner zu warten, wurde Hydraulic Conveyor als Packaging-Lösung eingeführt. Conveyor erlaubt den Bau von Windows-MSI-Paketen direkt auf Linux, indem es eigene Toolchains mitbringt.

• conveyor.conf erstellt: Zentrale Konfiguration für die Desktop-App (Icons, JVM-Argumente, Windows-spezifische GUIDs).
• Eingangsquelle: Nutzt das JVM-JAR des Desktop-Shell-Moduls als Input.

2. 🐧 Gitea-Workflow Update

Der Workflow .gitea/workflows/feature-build.yml wurde radikal umgebaut:

• Runner-Wechsel: Von windows-latest (der nie existierte) auf ubuntu-latest.
• Build-Schritte:
  1. Gradle jvmJar erstellt die Plattform-unabhängige JAR.
  2. Installation von Conveyor via CLI.
  3. conveyor make windows-msi erzeugt das Paket.
• Artefakte: Die resultierende .msi-Datei wird nun korrekt in der Gitea-UI hochgeladen.

Status: In Arbeit (Verifikation ausstehend)

• CI-Update: Die Blockade durch die Variable DESKTOP_CI_ENABLED wurde entfernt. Der Workflow läuft nun bei jedem Push auf einen Feature-Branch.
• Input-Fix: Die conveyor.conf wurde auf das spezifische JAR-Namensmuster (meldestelle-desktop-jvm-*.jar) angepasst.
• Workflow-Stabilisierung: Das Installations-Skript wurde um eine HTML-Validierung und einen npm-Fallback erweitert, da die offizielle Download-URL im Runner instabil war (Log #481).
• Nächster Schritt: Beobachtung des nächsten CI-Laufs in Gitea (Task #482+). Sobald das MSI bereitsteht, erfolgt der Hardware-Test.

🏗️ [Lead Architect] 🐧 [DevOps Engineer]