sorb/ThreadNet-Web
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 4 Wiki Activity

[MEDIUM] Windows-Desktop-Build-Strecke in der GitLab-CI #5

New Issue
Closed
opened 2026-07-31 11:10:18 +00:00 by sorb · 5 comments
sorb commented 2026-07-31 11:10:18 +00:00
Owner
Copy Link
Copy Source

Nachfolger des Windows-Teils aus #2 (dort geschlossen, Linux-Strecke laeuft seit
2026-07-31 automatisch in der Lab-GitLab-CI).

Ziel: Windows-Desktop-Builds (x64) aus der GitLab-CI, analog zur Linux-Strecke.

Kontext/Befund: Der Upstream-Workflow (build_desktop_windows.yaml) setzt native
Windows-Runner voraus (signtool unter C:/Program Files, MSVC-Rust-Targets, PowerShell) -
nicht auf Linux-Runnern lauffaehig. Zwei Wege:

  1. Windows-VM als GitLab-Runner (empfohlen): gitlab-runner mit Shell-Executor auf einer
    Lab-Windows-VM, Upstream-Build-Logik uebersetzen. Planbarer Aufwand, hohe
    Erfolgswahrscheinlichkeit. Voraussetzung: Windows-VM im Lab (Entscheidung/Bereitstellung
    offen).
  2. Wine-Cross-Build (electronuserland/builder:wine): kein neuer Runner noetig, aber
    deterministische Engineering-Huerden beim Cross-Kompilieren der nativen Rust-Module
    (seshat, MSVC-Target ohne Windows) - zeitlich begrenztes Experiment, kein verlaesslicher
    Plan. Wiederholtes Laufenlassen hilft NICHT, die Fehler sind reproduzierbar.

Signing (separat entscheidbar, Start unsigniert mit SmartScreen-Warnung vertretbar):
seit 2023 nur noch Hardware-Token/Cloud-Signing zulaessig. Realistische Optionen: Azure
Trusted Signing (~10$/Monat), Certum-OV-Token (guenstige Open-Source-Tarife), SSL.com
eSigner (nutzt Upstream, ESIGNER_*-Secrets).

Nachfolger des Windows-Teils aus #2 (dort geschlossen, Linux-Strecke laeuft seit 2026-07-31 automatisch in der Lab-GitLab-CI). **Ziel**: Windows-Desktop-Builds (x64) aus der GitLab-CI, analog zur Linux-Strecke. **Kontext/Befund**: Der Upstream-Workflow (`build_desktop_windows.yaml`) setzt native Windows-Runner voraus (signtool unter `C:/Program Files`, MSVC-Rust-Targets, PowerShell) - nicht auf Linux-Runnern lauffaehig. Zwei Wege: 1. **Windows-VM als GitLab-Runner** (empfohlen): gitlab-runner mit Shell-Executor auf einer Lab-Windows-VM, Upstream-Build-Logik uebersetzen. Planbarer Aufwand, hohe Erfolgswahrscheinlichkeit. Voraussetzung: Windows-VM im Lab (Entscheidung/Bereitstellung offen). 2. **Wine-Cross-Build** (`electronuserland/builder:wine`): kein neuer Runner noetig, aber deterministische Engineering-Huerden beim Cross-Kompilieren der nativen Rust-Module (seshat, MSVC-Target ohne Windows) - zeitlich begrenztes Experiment, kein verlaesslicher Plan. Wiederholtes Laufenlassen hilft NICHT, die Fehler sind reproduzierbar. **Signing** (separat entscheidbar, Start unsigniert mit SmartScreen-Warnung vertretbar): seit 2023 nur noch Hardware-Token/Cloud-Signing zulaessig. Realistische Optionen: Azure Trusted Signing (~10$/Monat), Certum-OV-Token (guenstige Open-Source-Tarife), SSL.com eSigner (nutzt Upstream, `ESIGNER_*`-Secrets).
sorb commented 2026-07-31 11:19:28 +00:00
Author
Owner
Copy Link
Copy Source

Sicherheitsbewertung dockur/windows (2026-07-31, Quellcode-Review):

Solide: 52.7k Stars, MIT, aktiv; ISOs von offiziellen Microsoft-Endpoints
(go.microsoft.com/fwlink, software-download-connector) mit SHA256-Pruefung gegen im Skript
hinterlegte Hashes bzw. Microsofts ESD-Kataloge; kein privileged noetig (nur /dev/kvm,
/dev/net/tun, NET_ADMIN).

Vorbehalte: (1) Hash-Pruefung wird stillschweigend uebersprungen, wenn kein Hash hinterlegt
ist; (2) Gast-Defaults unsicher (User Docker/admin, RDP 3389 offen) - Haertung Pflicht:
eigenes PASSWORD, keine Ports publishen (Runner braucht nur outbound zu git.lab);
(3) keine Provenance/SBOM fuer die fertigen Hub-Images.

Entscheidung: Image selbst bauen aus reviewtem, gepinntem Quellstand (Repo nach git.lab
vendoren, Lab-CI baut, Push nach rohana) statt Docker-Hub-Image zu vertrauen. Basis-Image
qemus/qemu als gepinnter Digest.

Machbarkeit Overmind (geprueft 2026-07-31): /dev/kvm vorhanden, 14 Kerne, 137G Disk frei

  • passt. RAM ist der Engpass: 9,5Gi verfuegbar (Swap bereits in Nutzung) -> VM mit 6-8G nur
    on-demand starten (manueller Start-Job auf dem Linux-Runner via Docker-Socket), nicht
    parallel zu schweren Linux-Builds. Windows-Job bleibt when:manual mit tags:[windows].
**Sicherheitsbewertung dockur/windows** (2026-07-31, Quellcode-Review): Solide: 52.7k Stars, MIT, aktiv; ISOs von offiziellen Microsoft-Endpoints (go.microsoft.com/fwlink, software-download-connector) mit SHA256-Pruefung gegen im Skript hinterlegte Hashes bzw. Microsofts ESD-Kataloge; kein privileged noetig (nur /dev/kvm, /dev/net/tun, NET_ADMIN). Vorbehalte: (1) Hash-Pruefung wird stillschweigend uebersprungen, wenn kein Hash hinterlegt ist; (2) Gast-Defaults unsicher (User Docker/admin, RDP 3389 offen) - Haertung Pflicht: eigenes PASSWORD, keine Ports publishen (Runner braucht nur outbound zu git.lab); (3) keine Provenance/SBOM fuer die fertigen Hub-Images. **Entscheidung**: Image selbst bauen aus reviewtem, gepinntem Quellstand (Repo nach git.lab vendoren, Lab-CI baut, Push nach rohana) statt Docker-Hub-Image zu vertrauen. Basis-Image qemus/qemu als gepinnter Digest. **Machbarkeit Overmind** (geprueft 2026-07-31): /dev/kvm vorhanden, 14 Kerne, 137G Disk frei - passt. RAM ist der Engpass: 9,5Gi verfuegbar (Swap bereits in Nutzung) -> VM mit 6-8G nur on-demand starten (manueller Start-Job auf dem Linux-Runner via Docker-Socket), nicht parallel zu schweren Linux-Builds. Windows-Job bleibt when:manual mit tags:[windows].
sorb commented 2026-07-31 12:10:16 +00:00
Author
Owner
Copy Link
Copy Source

Umsetzung gestartet (2026-07-31):

  • Vendor-Kopie: git.lab/axion1337.chat/vendor/windows, Upstream-Pin
    7645a2b34fe8a79984664eb849cecd4e08d66c5e     (dockur/windows master, 2026-07-30)
  • Review am Pin: Basis qemux/qemu per Tag (7.42) gepinnt, nicht per Digest; wsdd/virtio/
    Blinter versionsgepinnt via HTTPS. Unattended-Setup schaltet die Gast-Firewall aus und
    aktiviert RDP - fuer unseren Runner-Anwendungsfall wird beides nach der Provisionierung
    zurueckgedreht (Runner braucht nur outbound; noVNC laeuft ueber QEMU, nicht RDP). Steht so
    im Runbook.
  • Eigenes Image wird per Lab-CI aus dem Pin gebaut -> rohana.axion1337.de/sorb/windows-vm
  • Overmind-Zahlen aktualisiert (nach Aufraeumen): 11 Gi RAM verfuegbar, 278 G Disk frei -
    komfortabel fuer die 8G-VM im On-Demand-Betrieb
**Umsetzung gestartet (2026-07-31)**: - Vendor-Kopie: `git.lab/axion1337.chat/vendor/windows`, **Upstream-Pin `7645a2b34fe8a79984664eb849cecd4e08d66c5e`** (dockur/windows master, 2026-07-30) - Review am Pin: Basis `qemux/qemu` per Tag (7.42) gepinnt, nicht per Digest; wsdd/virtio/ Blinter versionsgepinnt via HTTPS. Unattended-Setup schaltet die **Gast-Firewall aus** und aktiviert RDP - fuer unseren Runner-Anwendungsfall wird beides nach der Provisionierung zurueckgedreht (Runner braucht nur outbound; noVNC laeuft ueber QEMU, nicht RDP). Steht so im Runbook. - Eigenes Image wird per Lab-CI aus dem Pin gebaut -> `rohana.axion1337.de/sorb/windows-vm` - Overmind-Zahlen aktualisiert (nach Aufraeumen): 11 Gi RAM verfuegbar, 278 G Disk frei - komfortabel fuer die 8G-VM im On-Demand-Betrieb
sorb commented 2026-07-31 16:28:54 +00:00
Author
Owner
Copy Link
Copy Source

Geparkt (2026-08-01, Nacht-Session) - Runner-Dienst im Gast kommt nicht hoch:

Stand: VM provisioniert und gehaertet, Runner lab-windows-1 war online und hat 4 Jobs
verarbeitet (Checkout-Kette funktionierte nach longpaths-Fix). Nach dem Dienst-Neustart am
Ende des zweiten windows_provision-Laufs (15:27 UTC) meldet sich der Runner nicht mehr -
weder nach docker restart windows-runner (User) noch nach docker start via CI-Job
(lief erfolgreich, Container laeuft also). Diagnose von aussen ausgeschoepft; noVNC/RDP-Ports
sind bereits dicht (Haertung abgeschlossen).

Naechster Schritt (User, ~5 min): Port-Zeile 127.0.0.1:8006:8006 temporaer wieder in
den windows-runner-Stack, per SSH-Tunnel in noVNC schauen. Wahrscheinlichste Befunde:

  1. VM haengt im Boot/Update -> abwarten oder neustarten
  2. Dienst gestoppt -> in Admin-PowerShell: Start-Service gitlab-runner bzw.
    C:\GitLab-Runner\gitlab-runner.exe start; Status: Get-Service gitlab-runner
    Danach Port wieder raus. Sobald der Runner online ist: desktop_windows (Pipeline 107,
    Job 399) spielen - alle bisherigen Fixes (git, longpaths, Provisionierung) sind drin,
    naechste erwartbare Huerden waeren pnpm-PATH oder VS-DevShell.

Bereits eingeplante Robustheits-Verbesserung: der Dienst-Neustart im
windows_provision-Job wird auf einen Windows Scheduled Task umgestellt (schtasks /sc once) - der Start-Process-Trick wird beim Job-Ende vom Runner-Prozessbaum-Cleanup
gekillt (Race, genau das hat den Dienst diesmal gestoppt zurueckgelassen).

**Geparkt (2026-08-01, Nacht-Session) - Runner-Dienst im Gast kommt nicht hoch:** Stand: VM provisioniert und gehaertet, Runner `lab-windows-1` war online und hat 4 Jobs verarbeitet (Checkout-Kette funktionierte nach longpaths-Fix). Nach dem Dienst-Neustart am Ende des zweiten `windows_provision`-Laufs (15:27 UTC) meldet sich der Runner nicht mehr - weder nach `docker restart windows-runner` (User) noch nach `docker start` via CI-Job (lief erfolgreich, Container laeuft also). Diagnose von aussen ausgeschoepft; noVNC/RDP-Ports sind bereits dicht (Haertung abgeschlossen). **Naechster Schritt (User, ~5 min)**: Port-Zeile `127.0.0.1:8006:8006` temporaer wieder in den windows-runner-Stack, per SSH-Tunnel in noVNC schauen. Wahrscheinlichste Befunde: 1. VM haengt im Boot/Update -> abwarten oder neustarten 2. Dienst gestoppt -> in Admin-PowerShell: `Start-Service gitlab-runner` bzw. `C:\GitLab-Runner\gitlab-runner.exe start`; Status: `Get-Service gitlab-runner` Danach Port wieder raus. Sobald der Runner online ist: `desktop_windows` (Pipeline 107, Job 399) spielen - alle bisherigen Fixes (git, longpaths, Provisionierung) sind drin, naechste erwartbare Huerden waeren pnpm-PATH oder VS-DevShell. **Bereits eingeplante Robustheits-Verbesserung**: der Dienst-Neustart im `windows_provision`-Job wird auf einen Windows Scheduled Task umgestellt (`schtasks /sc once`) - der `Start-Process`-Trick wird beim Job-Ende vom Runner-Prozessbaum-Cleanup gekillt (Race, genau das hat den Dienst diesmal gestoppt zurueckgelassen).
sorb commented 2026-07-31 19:51:16 +00:00
Author
Owner
Copy Link
Copy Source

Erledigt — erster vollständiger Windows-Build ist durch (2026-07-31, ~21:50 lokal).

desktop_windows Job 438 (Pipeline 113, git.lab): success, 7m11s. Artifact: Element Setup 1.12.17.exe (141 MB, NSIS, unsigniert), per API verifiziert. VM danach über stop_windows_vm heruntergefahren.

Was auf dem Weg gefixt wurde (11 Anläufe, alle Fixes committet):

  • Provisionierung (windows_provision-Job): choco-Pakete einzeln (git, nasm, tcl, node 24.15); dazu Strawberry Perl (perl+patch), Python, Rust maschinenweit unter C:\Rust (SYSTEM-Dienst sieht kein Benutzerprofil), NASM-PATH; core.longpaths+LongPathsEnabled (MAX_PATH); Dienst-Neustart via Scheduled Task statt Start-Process (Runner-Cleanup-Race).
  • CA: Windows verlangt die selbstsignierte Root im Root-Store, Intermediate reicht nicht (Runbook korrigiert).
  • GitHub-CDN-Abrisse (Electron-Zip, winCodeSign, NSIS): resumefähiges Prefetch-Skript apps/desktop/axion1337/prefetch-buildcache.ps1 mit verifiziertem app-builder-Cache-Layout (<Cache>\<prefix>\<release>-<release>).
  • Host-Ausfall zwischendurch war nicht die Build-VM, sondern der e1000e-NIC-Hang (Backlogs OVERMIND-02, EEE-Fix aktiv).

Doku: Runbook docs/axion-runner.md im Vendor-Repo (git.lab/axion1337.chat/vendor/windows), Backlogs hosts/overmind.md.

Offen (Folge-Issues): Signing (separates Issue), Installer-Branding — der Installer heißt noch „Element Setup" (Upstream-Variante; aXion-VARIANT_PATH fürs Desktop-Packaging wäre der nächste Feinschliff).

**Erledigt — erster vollständiger Windows-Build ist durch** (2026-07-31, ~21:50 lokal). `desktop_windows` Job 438 (Pipeline 113, git.lab): **success**, 7m11s. Artifact: `Element Setup 1.12.17.exe` (141 MB, NSIS, unsigniert), per API verifiziert. VM danach über `stop_windows_vm` heruntergefahren. Was auf dem Weg gefixt wurde (11 Anläufe, alle Fixes committet): - **Provisionierung** (`windows_provision`-Job): choco-Pakete einzeln (git, nasm, tcl, node 24.15); dazu Strawberry Perl (perl+patch), Python, **Rust maschinenweit** unter `C:\Rust` (SYSTEM-Dienst sieht kein Benutzerprofil), NASM-PATH; `core.longpaths`+`LongPathsEnabled` (MAX_PATH); Dienst-Neustart via Scheduled Task statt `Start-Process` (Runner-Cleanup-Race). - **CA**: Windows verlangt die selbstsignierte Root im Root-Store, Intermediate reicht nicht (Runbook korrigiert). - **GitHub-CDN-Abrisse** (Electron-Zip, winCodeSign, NSIS): resumefähiges Prefetch-Skript `apps/desktop/axion1337/prefetch-buildcache.ps1` mit verifiziertem app-builder-Cache-Layout (`<Cache>\<prefix>\<release>-<release>`). - Host-Ausfall zwischendurch war **nicht** die Build-VM, sondern der e1000e-NIC-Hang (Backlogs OVERMIND-02, EEE-Fix aktiv). Doku: Runbook `docs/axion-runner.md` im Vendor-Repo (git.lab/axion1337.chat/vendor/windows), Backlogs `hosts/overmind.md`. Offen (Folge-Issues): Signing (separates Issue), Installer-Branding — der Installer heißt noch „Element Setup" (Upstream-Variante; aXion-`VARIANT_PATH` fürs Desktop-Packaging wäre der nächste Feinschliff).
sorb closed this issue 2026-07-31 19:51:16 +00:00
sorb commented 2026-08-01 14:25:50 +00:00
Author
Owner
Copy Link
Copy Source

Migriert nach git.lab: axion1337.chat/ThreadNet-Web#5 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

**Migriert nach git.lab**: [axion1337.chat/ThreadNet-Web#5](https://git.lab/axion1337.chat/ThreadNet-Web/-/issues/5) (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
sorb (ScrublordMcBad)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/ThreadNet-Web#5