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 <noreply@anthropic.com>
This commit is contained in:
+8
-9
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user