From b98f4e15c9c1e5948cabc218d9596e4b03fb9cd1 Mon Sep 17 00:00:00 2001 From: D4rkst3r Date: Wed, 12 Aug 2026 15:00:51 +0200 Subject: [PATCH] fix: pull_policy build -- der Auto-Deploy zog, baute aber nie Der erste Verdacht ("kein Runner") war die halbe Wahrheit. Portainers GitOps-Weg funktioniert, nachgemessen in seinem eigenen Datenverzeichnis: /d/compose/1/src/melden.js 12:48 <- die Uhrzeit des Pushes /d/compose/1/stack.env 12:57 <- Portainer hat neu geschrieben docker images d4rkbot:latest 00:21 <- das Abbild 15 Stunden alt Portainer holt den neuen Stand also brav ins Stack-Verzeichnis und ruft dann docker compose up -d. UND DAS BAUT NUR, WENN DAS ABBILD FEHLT. d4rkbot:latest gab es -- also kein Bau, kein neuer Container, und der Bot lief weiter mit dem Code von vorgestern. Kein Runner, kein Webhook, keine Fehlermeldung: es sah nach "nichts zu tun" aus. Das ist die unangenehme Sorte Fehler -- man pusht, hakt es ab, und der Fehler, den man gerade behoben hat, laeuft weiter. pull_policy: build laesst compose bei jedem Ausrollen neu bauen. Geprueft mit docker compose config (v5.3.1 nimmt es an und gibt es aufgeloest zurueck). Einmal noch von Hand, denn die Zeile wirkt erst, wenn sie selbst ausgerollt ist: Portainer -> Stack ecobot -> Pull and redeploy. Co-Authored-By: Claude Opus 5 --- docker-compose.yml | 12 ++++++++++++ docs/befunde-2026-08-12.md | 33 ++++++++++++++++++++++++++++++--- 2 files changed, 42 insertions(+), 3 deletions(-) diff --git a/docker-compose.yml b/docker-compose.yml index 8d228bf..be2e750 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -5,6 +5,18 @@ services: d4rkbot: build: . image: d4rkbot:latest + # IMMER neu bauen, nicht 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 ist die unangenehme Sorte Fehler -- man pusht, hakt es ab, und der + # Fehler, den man gerade behoben hat, laeuft weiter. + pull_policy: build container_name: d4rkbot restart: unless-stopped # Werte kommen per Interpolation: lokal aus der .env im Projektordner (liest diff --git a/docs/befunde-2026-08-12.md b/docs/befunde-2026-08-12.md index b54fe7a..03219ed 100644 --- a/docs/befunde-2026-08-12.md +++ b/docs/befunde-2026-08-12.md @@ -314,9 +314,36 @@ Code im Container grep pruefeSicherung -> 0 <- der alte Stand abarbeitet — und der Webhook-Weg (der ohne Runner auskäme) ist offenbar auch nicht eingerichtet. -**Das heißt: pushen allein rollt nichts aus.** Bis einer der beiden Wege steht, -gilt weiterhin der Weg von Hand — Portainer → Stack `ecobot` → *Pull and -redeploy*. +### Nachgefasst: er zieht, aber er baut nicht + +Der erste Verdacht („kein Runner") war nur die halbe Wahrheit. Portainers +GitOps-Weg **funktioniert** — nachgemessen in seinem eigenen Datenverzeichnis: + +``` +/d/compose/1/src/melden.js 12:48 <- die Uhrzeit meines Pushes +/d/compose/1/stack.env 12:57 <- Portainer hat neu geschrieben +docker images d4rkbot:latest 00:21 <- das Abbild ist 15 Stunden alt +``` + +Portainer holt den neuen Stand also brav ins Stack-Verzeichnis und ruft dann +`docker compose up -d`. **Und das baut nur, wenn das Abbild fehlt.** +`d4rkbot:latest` gab es — also kein Bau, kein neuer Container, und der Bot lief +weiter mit dem Code von vorgestern. Kein Runner, kein Webhook und keine +Fehlermeldung; es sah nach „nichts zu tun" aus. + +**Die Zeile, die gefehlt hat**, steht jetzt in `docker-compose.yml`: + +```yaml +pull_policy: build +``` + +Damit baut `docker compose up -d` das Abbild bei jedem Ausrollen neu. Geprüft +mit `docker compose config` (Compose v5.3.1 nimmt es an und gibt es aufgelöst +zurück). + +**Einmal noch von Hand**, denn die Zeile wirkt erst, wenn sie selbst ausgerollt +ist: Portainer → Stack `ecobot` → *Pull and redeploy*. Danach greift der +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