cddba14993
tests / pest (push) Waiting to run
Details
tests / assets (push) Waiting to run
Details
tests / release (push) Blocked by required conditions
Details
Bei zehn Servern laesst sich eine Auslieferung heute nicht staffeln: entweder alle nehmen die neueste Version oder niemand. Der einzige Griff, der eine bestimmte setzt, ist `RELEASE=vX.Y.Z bash deploy/update.sh` auf der Kommandozeile — zehnmal. Zwei Funde haben den Entwurf geformt: - Zurueckrollen ist kein fehlender Knopf, sondern eine bewusst verbotene Handlung (update.sh:222). Die Fehlermeldung dort verweist auf einen Datenbank-Schnappschuss vor dem Update — den nimmt niemand, in update.sh steht kein einziger Dump. Echtes Zurueckrollen ist deshalb eine eigene Baustelle, und ihr fehlendes Stueck ist der Schnappschuss, nicht der Knopf. - `clupilot:auto-update` haette einen einmaligen Sprung beim naechsten Wartungsfenster sofort wieder auf die neueste Version gehoben. Festnageln muss also eine stehende Obergrenze sein, sonst haelt es nicht. Der Ansatz ist dadurch klein: der Agent uebergibt in Zeile 669 ohnehin schon `RELEASE="$TARGET_RELEASE"`. Wird diese eine Variable auf die Decke geklemmt, folgt alles andere — `behind` faellt aus derselben Rechnung, und Knopf wie Automatik lesen beide `UpdateChannel::state()`. Kein zweiter Weg in eine Auslieferung. Entscheidend beim Fehlerverhalten: die Decke faellt zu, nicht auf. Eine unlesbare oder ins Leere zeigende Decke darf nicht auf „neueste Version" zurueckfallen — das installierte genau das, wovon weggenagelt wurde. Dass ein Tag verschwindet, ist dabei kein Randfall: der Release-Prozess loescht falsche Tags und ueberspringt die Nummer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| design | ||
| handoffs | ||
| runbooks | ||
| specs | ||
| superpowers | ||
| deployment.md | ||
| handoff-plan-catalogue.md | ||
| monitoring-uptime-kuma.md | ||
| wireguard-hub.md | ||