27 lines
1.5 KiB
Markdown
27 lines
1.5 KiB
Markdown
 
|
---
|
||
|
|
type: issue
|
||
|
|
id: "0021"
|
||
|
|
status: waiting
|
||
|
|
created: 2026-08-02
|
||
|
|
milestone: M2
|
||
|
|
priority: medium
|
||
|
|
area: infrastructure
|
||
|
|
wartegrund: Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren
|
||
|
|
gitlab_iid: "21"
|
||
|
|
related: []
|
||
|
|
---
|
||
|
|
# OVERMIND-03: Windows-Build-VM verschwindet — CI kann sie nur starten, nicht anlegen
|
||
|
|
|
||
|
|
> Import aus [management#21](https://git.lab/axion1337.chat/management/-/issues/21) (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).
|
||
|
|
|
||
|
|
Der CI-Job `start_windows_vm` macht ausschließlich `docker start windows-runner`. Existiert der Container nicht, scheitert er mit `No such container: windows-runner` — so geschehen am 2026-08-02 (Job 498), nachdem der Container zwischenzeitlich verschwunden war (vermutlich durch einen Dokploy-Redeploy oder den Host-Neustart; nicht verifiziert).
|
||
|
|
|
||
|
|
sorb hat ihn manuell neu gestartet, danach lief der Build. Der Fall wiederholt sich aber, sobald der Stack erneut angefasst wird.
|
||
|
|
|
||
|
|
**Optionen:**
|
||
|
|
- **A** — Job robuster machen: bei fehlendem Container den Dokploy-Stack `windows-runner` per API neu deployen statt nur zu starten.
|
||
|
|
- **B** — Container über `restart: unless-stopped` dauerhaft halten. ⚠️ Widerspricht dem On-demand-Prinzip (die VM belegt 8 GB) und war eine bewusste Entscheidung.
|
||
|
|
- **C** — so lassen, aber die Fehlermeldung im Job um den Hinweis „Stack in Dokploy neu deployen" ergänzen (billigste Variante).
|
||
|
|
|
||
|
|
Empfehlung: **C jetzt, A wenn es ein drittes Mal passiert.**
|