chore: SQLite-Datenbank aus der Versionierung nehmen
backend/data/rss_news.db lag im Repo. Auf dem Server liegt unter demselben Pfad die Produktivdatenbank mit 95 MB, im Repo ein Entwicklungsstand mit 200 KB. Jeder Commit, der die Datei mitgenommen haette, haette beim naechsten Deploy die Live-Daten damit ueberschrieben. Die Datei wird untracked (bleibt auf der Platte liegen), *.db und backend/data/ wandern in die .gitignore. init_db() legt die Datenbank beim ersten Start selbst an. Ausserdem: docs/AUTOMATION.md behauptete automatisches Deployment ueber GitHub Actions. Das stimmt nicht - das Remote ist Forgejo ohne Runner, und der Server hat keinen Deploy-Key, `git pull origin main` scheitert dort mit Permission denied. Der tatsaechliche Handbetrieb per Git-Bundle ist jetzt dokumentiert, die Reparatur steht in der TODO. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
208940da3f
commit
b976fc3036
4 changed files with 51 additions and 6 deletions
11
.gitignore
vendored
11
.gitignore
vendored
|
|
@ -23,6 +23,17 @@ Thumbs.db
|
||||||
# dotenv / Umgebungsvariablen
|
# dotenv / Umgebungsvariablen
|
||||||
.env
|
.env
|
||||||
|
|
||||||
|
# SQLite-Datenbanken NIE versionieren.
|
||||||
|
# Die Produktivdatenbank liegt auf dem Server unter demselben Pfad
|
||||||
|
# (backend/data/rss_news.db, 95 MB). Solange die Datei im Repo lag, haette
|
||||||
|
# jeder Commit, der sie mitnimmt, beim naechsten Deploy die Live-Daten mit
|
||||||
|
# einem Entwicklungsstand ueberschrieben. init_db() legt die Datei beim
|
||||||
|
# ersten Start selbst an.
|
||||||
|
*.db
|
||||||
|
*.db-wal
|
||||||
|
*.db-shm
|
||||||
|
backend/data/
|
||||||
|
|
||||||
# JSON-Datenbanken / Zwischenspeicherung
|
# JSON-Datenbanken / Zwischenspeicherung
|
||||||
# *.json
|
# *.json
|
||||||
# !feeds.json # optional entfernbar, wenn du Beispielfeeds mit versionieren willst
|
# !feeds.json # optional entfernbar, wenn du Beispielfeeds mit versionieren willst
|
||||||
|
|
|
||||||
Binary file not shown.
|
|
@ -198,14 +198,45 @@ Alle externen Endpunkte benötigen den Header `X-API-Key: <N8N_API_KEY>`.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Deployment (Hetzner via GitHub)
|
## Deployment (Hetzner)
|
||||||
|
|
||||||
Das Deployment läuft automatisch über GitHub Actions beim Push auf `main`:
|
**Achtung: Das Deployment läuft derzeit NICHT automatisch.** Stand 24.08.2026
|
||||||
|
geprüft — `.github/workflows/deploy.yml` ist GitHub-Actions-Syntax, das Remote
|
||||||
|
ist aber Forgejo (`git.giertz.biz`), und es greift kein Runner. Zusätzlich hat
|
||||||
|
der Server keinen Deploy-Key für das Repo: `git pull origin main` scheitert dort
|
||||||
|
mit `Permission denied (publickey)`. Ein Push auf `main` bewirkt also nichts.
|
||||||
|
|
||||||
1. GitHub Action führt Tests aus
|
Bis das repariert ist, wird von Hand deployt. Weg über ein Git-Bundle, damit die
|
||||||
2. Bei Erfolg: SSH-Deploy auf Hetzner
|
Historie auf dem Server korrekt bleibt (statt Dateien zu kopieren und die Stände
|
||||||
3. `pip install -r requirements.txt`
|
unbemerkt auseinanderdriften zu lassen):
|
||||||
4. Systemd-Dienst `rss-app` neu starten
|
|
||||||
|
```bash
|
||||||
|
# lokal, <alt> = Commit, auf dem der Server steht
|
||||||
|
git bundle create /tmp/deploy.bundle <alt>..main
|
||||||
|
scp /tmp/deploy.bundle hetzner:/root/deploy.bundle
|
||||||
|
|
||||||
|
# auf dem Server
|
||||||
|
cd /opt/rss-news
|
||||||
|
git pull /root/deploy.bundle main
|
||||||
|
systemctl restart rss-news-api # zieht die DB-Migration automatisch nach
|
||||||
|
```
|
||||||
|
|
||||||
|
`pip install` nur, wenn sich `requirements.txt` oder `backend/requirements.txt`
|
||||||
|
tatsächlich geändert haben.
|
||||||
|
|
||||||
|
Dienst: `rss-news-api` (systemd), `WorkingDirectory=/opt/rss-news`,
|
||||||
|
uvicorn auf `127.0.0.1:8790`, davor der Reverse Proxy.
|
||||||
|
|
||||||
|
**Vor jedem Deploy die Datenbank sichern:**
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ssh hetzner "cp -a /opt/rss-news/backend/data/rss_news.db \
|
||||||
|
/root/rss-news-backups/rss_news.db.$(date +%F-%H%M)"
|
||||||
|
```
|
||||||
|
|
||||||
|
Dauerhafte Reparatur (offen): entweder einen Deploy-Key auf dem Server
|
||||||
|
hinterlegen und in Forgejo eintragen, oder den Workflow nach
|
||||||
|
`.forgejo/workflows/` umziehen und einen Runner registrieren.
|
||||||
|
|
||||||
Workflow-Dateien: `.github/workflows/test.yml` und `.github/workflows/deploy.yml`
|
Workflow-Dateien: `.github/workflows/test.yml` und `.github/workflows/deploy.yml`
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -34,6 +34,9 @@
|
||||||
- [x] Manuelle Rechtsfreigabe als Publish-Gate
|
- [x] Manuelle Rechtsfreigabe als Publish-Gate
|
||||||
|
|
||||||
## Betrieb
|
## Betrieb
|
||||||
|
- [ ] Deploy reparieren: Server hat keinen Deploy-Key (`git pull` scheitert), Forgejo hat keinen
|
||||||
|
Runner fuer `.github/workflows/deploy.yml`. Bis dahin Handbetrieb per Bundle, siehe `docs/AUTOMATION.md`.
|
||||||
|
- [x] `backend/data/rss_news.db` aus der Versionierung genommen (Live-DB 95 MB, Repo-Stand 200 KB)
|
||||||
- [ ] Systemd-Service(s) fuer API/Worker erstellen
|
- [ ] Systemd-Service(s) fuer API/Worker erstellen
|
||||||
- [ ] Nginx-Routing fuer neue App einrichten
|
- [ ] Nginx-Routing fuer neue App einrichten
|
||||||
- [ ] Healthcheck-Endpunkte + Monitoring einrichten
|
- [ ] Healthcheck-Endpunkte + Monitoring einrichten
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue