Files
d4rkbot/docker-compose.yml
D4rkst3randClaude Opus 5 40ede9c56a
Deploy / check (push) Canceled after 0s
Deploy / deploy (push) Canceled after 0s
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>
2026-08-12 15:03:18 +02:00

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: