D4rkst3randClaude Fable 5
b5617a9d18
- Repo-Backups: nachts um 04:00 werden alle Gitea-Repos als git-Bundle gesichert — eine Datei pro Repo mit kompletter Historie, aus der sich direkt wieder klonen lässt. 14 Tage Rotation wie beim DB-Backup, Schalter und "Repos jetzt sichern" im System-Tab. Nutzt den bereits vorhandenen Gitea-Token; Dockerfile installiert dafür git mit. - Gitea-Theme im D4RKST3R-Look (docs/gitea-theme/): Neon-Gelb/Orange auf Schwarz, gebaut gegen die Variablen von Gitea 1.26, Diff-Farben bleiben lesbar. Einbau-Anleitung liegt daneben. - Auto-Deploy statt manuellem "Pull and redeploy": Workflow für Gitea Actions (prüft Server-Syntax und Frontend-Build, bevor deployed wird) plus dokumentierter Runner-loser Weg über den Portainer-Webhook. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2.7 KiB
Auto-Deploy statt „Pull and redeploy"
Bisher: pushen, in Portainer einloggen, Stack suchen, Pull and redeploy klicken. Das geht automatisch — zwei Wege, je nachdem wie viel du willst.
Weg 1: Portainer-Webhook (2 Minuten, kein Runner nötig) ← empfohlen
Portainer kann einen Stack per HTTP-Aufruf neu ausrollen. Gitea ruft diese Adresse nach jedem Push auf, fertig.
In Portainer:
- Stack
ecobotöffnen → Reiter Editor - Automatic updates einschalten, Methode Webhook
- Die erzeugte Webhook-URL kopieren
(Form:
https://portainer.../api/stacks/webhooks/<uuid>)
In Gitea:
- Repo
d4rkbot→ Einstellungen → Webhooks → Webhook hinzufügen → Gitea - Ziel-URL: die kopierte Portainer-Adresse
- HTTP-Methode
POST, Inhaltstypapplication/json - Trigger: Push-Ereignisse, Branch-Filter
main - Speichern, dann Zustellung testen — Portainer sollte den Stack neu bauen
Der Stack muss aus dem Git-Repository deployed sein (nicht aus einem hochgeladenen Compose-Text), damit Portainer den neuen Stand ziehen kann. „Re-pull image" bleibt aus — das Image wird ja lokal gebaut.
Weg 2: Gitea Actions (prüft den Code vor dem Deploy)
Der Workflow in .gitea/workflows/deploy.yml installiert die Abhängigkeiten,
prüft alle Server-Dateien auf Syntaxfehler, baut das Frontend — und stößt erst
dann das Redeploy an. Kaputter Code geht damit gar nicht erst live.
Voraussetzung: ein Act-Runner. In deiner Instanz sind Actions aktiviert, aber ohne Runner passiert nichts. Einrichten als zusätzlicher Container:
# docker-compose.yml für den Runner
services:
runner:
image: gitea/act_runner:latest
restart: always
environment:
GITEA_INSTANCE_URL: https://git.d4rkst3r.de
GITEA_RUNNER_REGISTRATION_TOKEN: <Token aus Gitea>
GITEA_RUNNER_NAME: d4rk-runner
GITEA_RUNNER_LABELS: ubuntu-latest:docker://node:22-bookworm
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./runner-data:/data
Den Registrierungs-Token findest du unter Site-Administration → Actions → Runner → Runner erstellen (oder pro Repo unter Einstellungen → Actions).
Secret hinterlegen: Repo → Einstellungen → Actions → Secrets →
PORTAINER_WEBHOOK mit der Portainer-Adresse. Fehlt das Secret, läuft nur die
Prüfung und der Deploy-Schritt wird übersprungen.
Welchen nehmen?
| Weg 1 (Webhook) | Weg 2 (Actions) | |
|---|---|---|
| Aufwand | 2 Minuten | Runner-Container aufsetzen |
| Prüft den Code | nein | ja (Syntax + Frontend-Build) |
| Läuft ohne Zusatzdienst | ja | nein |
Fang mit Weg 1 an. Weg 2 lohnt sich, sobald du Tests hast oder mehrere Leute pushen — dann verhindert er, dass ein kaputter Stand live geht.