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>
72 lines
2.7 KiB
Markdown
72 lines
2.7 KiB
Markdown
# 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:**
|
|
|
|
1. Stack `ecobot` öffnen → Reiter **Editor**
|
|
2. **Automatic updates** einschalten, Methode **Webhook**
|
|
3. Die erzeugte Webhook-URL kopieren
|
|
(Form: `https://portainer.../api/stacks/webhooks/<uuid>`)
|
|
|
|
**In Gitea:**
|
|
|
|
1. Repo `d4rkbot` → **Einstellungen → Webhooks → Webhook hinzufügen → Gitea**
|
|
2. Ziel-URL: die kopierte Portainer-Adresse
|
|
3. HTTP-Methode `POST`, Inhaltstyp `application/json`
|
|
4. Trigger: **Push-Ereignisse**, Branch-Filter `main`
|
|
5. 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:
|
|
|
|
```yaml
|
|
# 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.
|