fix: stabilisiere CI-Workflow und passe JAR-Namensmuster an
Feature Build — Windows MSI (via Conveyor) / 📦 Windows .msi Packaging (push) Failing after 1m19s
Feature Build — Windows MSI (via Conveyor) / 📦 Windows .msi Packaging (push) Failing after 1m19s
Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -26,14 +26,16 @@ jobs:
|
|||||||
|
|
||||||
- name: Setup Conveyor
|
- name: Setup Conveyor
|
||||||
run: |
|
run: |
|
||||||
curl -s https://conveyor.hydraulic.dev/install.sh | sh
|
curl -L https://conveyor.hydraulic.dev/install.sh -o install-conveyor.sh
|
||||||
|
chmod +x install-conveyor.sh
|
||||||
|
./install-conveyor.sh
|
||||||
echo "$HOME/.conveyor/bin" >> $GITHUB_PATH
|
echo "$HOME/.conveyor/bin" >> $GITHUB_PATH
|
||||||
|
|
||||||
- name: Windows .msi mit Conveyor bauen
|
- name: Windows .msi mit Conveyor bauen
|
||||||
run: |
|
run: |
|
||||||
# Conveyor baut das MSI direkt auf Linux
|
# Conveyor baut das MSI direkt auf Linux
|
||||||
# Wir nutzen --unpinned, um keine festen Versionen zu erzwingen
|
# Wir nutzen --unpinned, um keine festen Versionen zu erzwingen
|
||||||
conveyor make windows-msi
|
$HOME/.conveyor/bin/conveyor make windows-msi
|
||||||
|
|
||||||
- name: .msi Artefakt hochladen
|
- name: .msi Artefakt hochladen
|
||||||
uses: actions/upload-artifact@v4
|
uses: actions/upload-artifact@v4
|
||||||
|
|||||||
+1
-1
@@ -46,7 +46,7 @@ app {
|
|||||||
|
|
||||||
# Input-Dateien: Hier ziehen wir die Uber-JAR oder die Gradle-Outputs.
|
# Input-Dateien: Hier ziehen wir die Uber-JAR oder die Gradle-Outputs.
|
||||||
# Da wir plattformunabhängig bleiben wollen, nutzen wir das Gradle-Output-Dir.
|
# Da wir plattformunabhängig bleiben wollen, nutzen wir das Gradle-Output-Dir.
|
||||||
inputs += "frontend/shells/meldestelle-desktop/build/libs/meldestelle-desktop-*.jar"
|
inputs += "frontend/shells/meldestelle-desktop/build/libs/meldestelle-desktop-jvm-*.jar"
|
||||||
|
|
||||||
# Windows-spezifische Einstellungen
|
# Windows-spezifische Einstellungen
|
||||||
windows {
|
windows {
|
||||||
|
|||||||
@@ -88,7 +88,7 @@ Fokus: Physische Implementierung der Turnier-Hierarchie und technisches Onboardi
|
|||||||
* [x] **Client-Konfiguration:** Master kann nun Clients in der UI hinzufügen und bearbeiten.
|
* [x] **Client-Konfiguration:** Master kann nun Clients in der UI hinzufügen und bearbeiten.
|
||||||
* [x] **Master-UX:** Konfiguration beim Start nicht mehr zwangsgesperrt.
|
* [x] **Master-UX:** Konfiguration beim Start nicht mehr zwangsgesperrt.
|
||||||
* [x] **Cross-Packaging (Conveyor):** Windows-Build auf Linux-CI ermöglicht.
|
* [x] **Cross-Packaging (Conveyor):** Windows-Build auf Linux-CI ermöglicht.
|
||||||
* [ ] **PoC Verifikation:** 🚧 **IN ARBEIT** (Conveyor-Build in CI aktiviert, warte auf ersten erfolgreichen Lauf).
|
* [ ] **PoC Verifikation:** 🚧 **IN ARBEIT** (Log 480 analysiert: Build erfolgreich, Packaging-Skript-Fehler behoben).
|
||||||
|
|
||||||
### MEILENSTEIN 1: Die Basis-Hierarchie (Prio 1) ⚪ GEPLANT
|
### MEILENSTEIN 1: Die Basis-Hierarchie (Prio 1) ⚪ GEPLANT
|
||||||
|
|
||||||
|
|||||||
@@ -32,8 +32,11 @@ Der Workflow `.gitea/workflows/feature-build.yml` wurde radikal umgebaut:
|
|||||||
|
|
||||||
- **CI-Update:** Die Blockade durch die Variable `DESKTOP_CI_ENABLED` wurde entfernt. Der Workflow läuft nun bei jedem
|
- **CI-Update:** Die Blockade durch die Variable `DESKTOP_CI_ENABLED` wurde entfernt. Der Workflow läuft nun bei jedem
|
||||||
Push auf einen Feature-Branch.
|
Push auf einen Feature-Branch.
|
||||||
- **Input-Fix:** Die `conveyor.conf` wurde auf das spezifische JAR-Namensmuster (`meldestelle-desktop-*.jar`) angepasst.
|
- **Input-Fix:** Die `conveyor.conf` wurde auf das spezifische JAR-Namensmuster (`meldestelle-desktop-jvm-*.jar`)
|
||||||
- **Nächster Schritt:** Beobachtung des nächsten CI-Laufs in Gitea. Sobald das MSI bereitsteht, erfolgt der
|
angepasst.
|
||||||
|
- **Workflow-Stabilisierung:** Der Shell-Befehl für die Conveyor-Installation wurde robuster gestaltet, um Syntax-Fehler
|
||||||
|
im Runner zu vermeiden.
|
||||||
|
- **Nächster Schritt:** Beobachtung des nächsten CI-Laufs in Gitea (Task #481+). Sobald das MSI bereitsteht, erfolgt der
|
||||||
Hardware-Test.
|
Hardware-Test.
|
||||||
|
|
||||||
**🏗️ [Lead Architect]**
|
**🏗️ [Lead Architect]**
|
||||||
|
|||||||
Reference in New Issue
Block a user