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>
51 lines
2.2 KiB
YAML
51 lines
2.2 KiB
YAML
# d4rkbot Stack — deploybar über Portainer (Stacks → Add stack)
|
|
# WICHTIG: Portainer-Stack-Name "ecobot" NICHT ändern — er ist Teil des
|
|
# Volume-Namens (ecobot_ecobot_data); ein neuer Stack-Name = leeres Volume!
|
|
services:
|
|
d4rkbot:
|
|
build: .
|
|
image: d4rkbot:latest
|
|
# Immer neu bauen statt nur, wenn das Abbild fehlt.
|
|
#
|
|
# 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.
|
|
#
|
|
# 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
|
|
# Werte kommen per Interpolation: lokal aus der .env im Projektordner (liest
|
|
# docker compose automatisch), in Portainer aus den Stack-Environment-Variables
|
|
environment:
|
|
DISCORD_TOKEN: ${DISCORD_TOKEN}
|
|
DISCORD_CLIENT_ID: ${DISCORD_CLIENT_ID}
|
|
DISCORD_GUILD_ID: ${DISCORD_GUILD_ID:-}
|
|
COMMIT_CHANNEL_ID: ${COMMIT_CHANNEL_ID}
|
|
DEVLOG_CHANNEL_ID: ${DEVLOG_CHANNEL_ID}
|
|
DEVLOG_POST_SECRET: ${DEVLOG_POST_SECRET}
|
|
GITEA_API_TOKEN: ${GITEA_API_TOKEN:-}
|
|
GITEA_URL: ${GITEA_URL:-https://git.d4rkst3r.de}
|
|
GITEA_WEBHOOK_SECRET: ${GITEA_WEBHOOK_SECRET}
|
|
DISCORD_CLIENT_SECRET: ${DISCORD_CLIENT_SECRET}
|
|
SESSION_SECRET: ${SESSION_SECRET}
|
|
ADMIN_DISCORD_ID: ${ADMIN_DISCORD_ID}
|
|
PUBLIC_URL: ${PUBLIC_URL:-https://bot.d4rkst3r.de}
|
|
# Lokale Zeitzone — wichtig für den Wochen-Rückblick (sonntags 20:00) und Datumsangaben
|
|
TZ: ${TZ:-Europe/Berlin}
|
|
DB_PATH: /app/data/ecobot.db
|
|
# HTTP-Endpoint für Gitea-Webhooks + Webinterface
|
|
# NPM leitet bot.d4rkst3r.de → host.docker.internal:3080
|
|
ports:
|
|
- "3080:3080"
|
|
volumes:
|
|
# SQLite & Devlog-Bilder überleben Container-Neustarts.
|
|
# Volume-Name bleibt aus historischen Gründen "ecobot_data" (Daten!)
|
|
- ecobot_data:/app/data
|
|
|
|
volumes:
|
|
ecobot_data:
|