From 40ede9c56a19e3f77d21246cdd1d484afbd3aa94 Mon Sep 17 00:00:00 2001 From: D4rkst3r Date: Wed, 12 Aug 2026 15:03:18 +0200 Subject: [PATCH] docs: Richtigstellung -- der Auto-Deploy funktioniert, ich war zu ungeduldig Zwei falsche Diagnosen hintereinander, beide aus einem Zwischenstand geschlossen, waehrend der Vorgang noch lief. Was wirklich passiert ist: 12:48:18 Push 93156e5 12:48 Portainer hat die Dateien im Stack-Verzeichnis 12:57 hier gemessen: Abbild 15 h alt, Container von gestern -> daraus "er baut nicht" geschlossen. FALSCH. 13:01:02 Abbild neu gebaut 13:01:14 Container neu gestartet 13:02 pruefeSicherung im Container: 2, melden.js da, Panel HTTP 200 Zwischen Push und laufendem neuen Code liegen rund DREIZEHN MINUTEN -- Portainer fragt in Intervallen nach, nicht sofort. Die Messung um 12:57 fiel mitten in dieses Fenster: die Dateien waren schon da, das Abbild noch nicht neu. Aus dem Schnappschuss habe ich einen Systemfehler gemacht. Das ist genau der Fehler, gegen den der Bericht geschrieben ist -- eine plausible Erklaerung, die zum Schnappschuss passt, behauptet, bevor der Vorgang zu Ende war. pull_policy: build bleibt drin, aber NICHT mehr aus dem Grund im Commit davor. Es repariert nichts; es macht das Neubauen nur ausdruecklich, damit ein handgetipptes `docker compose up -d` dasselbe tut wie die Automatik. Folgenlos entfernbar. Co-Authored-By: Claude Opus 5 --- docker-compose.yml | 17 ++++++++-------- docs/befunde-2026-08-12.md | 40 +++++++++++++++++++++++++++++++++++++- 2 files changed, 47 insertions(+), 10 deletions(-) diff --git a/docker-compose.yml b/docker-compose.yml index be2e750..9a31ed5 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -5,17 +5,16 @@ services: d4rkbot: build: . image: d4rkbot:latest - # IMMER neu bauen, nicht nur wenn das Abbild fehlt. + # Immer neu bauen statt nur, wenn das Abbild fehlt. # - # Ohne das ist der Auto-Deploy ein Leerlauf, und das war er: Portainer zieht - # den neuen Stand brav ins Stack-Verzeichnis (nachgemessen -- die Dateien - # trugen die Uhrzeit des Pushes) und ruft dann `docker compose up -d`. Das - # baut aber nur, wenn das Abbild FEHLT. `d4rkbot:latest` gab es, also - # passierte nichts: kein Bau, kein Neustart, und der Bot lief weiter mit dem - # Code von vorgestern. + # Das REPARIERT NICHTS -- Portainer baut auch ohne diese Zeile neu, das ist + # nachgemessen worden (Push 12:48, Abbild 13:01:02, Container 13:01:14). Es + # dauert nur rund dreizehn Minuten, weil Portainer in Intervallen nachfragt, + # und wer waehrenddessen misst, haelt den Zwischenstand fuer das Ergebnis. # - # Das ist die unangenehme Sorte Fehler -- man pusht, hakt es ab, und der - # Fehler, den man gerade behoben hat, laeuft weiter. + # Die Zeile macht es nur ausdruecklich: bei einem Stack mit `build:` ist + # "immer neu bauen" das, was man beim Ausrollen will -- und wer spaeter von + # Hand `docker compose up -d` tippt, bekommt dasselbe wie die Automatik. pull_policy: build container_name: d4rkbot restart: unless-stopped diff --git a/docs/befunde-2026-08-12.md b/docs/befunde-2026-08-12.md index 03219ed..1fb0ec6 100644 --- a/docs/befunde-2026-08-12.md +++ b/docs/befunde-2026-08-12.md @@ -296,7 +296,7 @@ Setup → Einstellungen, und der Zweig läuft. --- -## ⚠️ Nachtrag: der Auto-Deploy hat nicht ausgelöst +## ~~Nachtrag: der Auto-Deploy hat nicht ausgelöst~~ — zwei falsche Diagnosen, siehe unten `docs/auto-deploy.md` beschreibt zwei Wege — Portainer-Webhook oder Gitea Actions. **Am 12.08.2026 hat keiner von beiden gegriffen.** Gemessen nach dem @@ -348,3 +348,41 @@ Auto-Deploy von allein. Das ist keine Kleinigkeit für die Zukunft: ein Deploy, von dem man glaubt, dass er automatisch läuft, ist schlimmer als gar keiner. Man pusht, hakt es ab, und der Fehler, den man gerade behoben hat, läuft weiter. + +### Richtigstellung: der Auto-Deploy funktioniert. Er ist nur langsamer als meine Geduld + +**Der Abschnitt oben war falsch, und zwar zweimal.** Erst hieß es „kein Runner, +also läuft gar nichts", dann „er zieht, aber er baut nicht". Beides war aus +einem Zwischenstand geschlossen, während der Vorgang noch lief. + +Was wirklich passiert ist: + +``` +12:48:18 Push 93156e5 +12:48 Portainer hat die Dateien im Stack-Verzeichnis +12:57 hier gemessen: Abbild 15 h alt, Container von gestern + -> daraus "er baut nicht" geschlossen. FALSCH. +13:01:02 Abbild neu gebaut +13:01:14 Container neu gestartet +13:02 pruefeSicherung im Container: 2 · melden.js: da · Panel: HTTP 200 +``` + +Zwischen Push und laufendem neuen Code liegen **rund dreizehn Minuten** — +Portainer fragt in Intervallen nach, nicht sofort. Meine Messung um 12:57 fiel +mitten in dieses Fenster: die Dateien waren schon da, das Abbild noch nicht neu. +Aus diesem Schnappschuss habe ich einen Systemfehler gemacht. + +**Das ist genau der Fehler, gegen den dieser Bericht geschrieben ist** — eine +plausible Erklärung, die zum Schnappschuss passt, behauptet, bevor der Vorgang +zu Ende war. Der Unterschied zu den anderen Befunden hier: bei denen wurde +gewartet, bis etwas fertig war. + +### Was mit `pull_policy: build` passiert + +Die Zeile steht weiter in `docker-compose.yml`, aber **nicht mehr aus dem Grund, +der im Commit davor stand**. Sie repariert nichts — Portainer baut auch ohne sie +neu. Sie macht es nur ausdrücklich: bei einem Stack mit `build:` ist „immer neu +bauen" das, was man beim Ausrollen will, und wer später von Hand +`docker compose up -d` tippt, bekommt dann dasselbe Ergebnis wie die Automatik. + +Wer sie nicht will, kann sie folgenlos entfernen.