Der Deploy-Job war seit seiner Einführung rot (Runs 99–107). Zwei Ursachen:
1. Die Repo-Secrets NAS_SSH_HOST/NAS_SSH_KEY waren in Gitea nie angelegt, der
Job baute also "ssh root@" mit leerer Key-Datei -> "Could not resolve
hostname". Secrets sind jetzt gesetzt (neuer Deploy-Key
gitea-ci-deploy@gerbilmanager, Pubkey in /root/.ssh/authorized_keys auf der
NAS) — das ist Server-Konfiguration, hier ändert sich dadurch nichts.
2. Danach scheiterte der Transfer an "rsync: command not found": der Guard
prüft nur `ssh`, und ssh ist im Runner-Image vorhanden, also lief der
apt-get-Zweig nie und rsync fehlte. Der Transfer nutzt jetzt `tar | ssh`
(tar existiert auf beiden Seiten, `-xof` erhält die Modi, die Deploy-Skripte
bleiben ausführbar); rsync ist aus dem apt-Aufruf entfernt.
Transfer und truenas-deploy.sh vorab per SSH gegen die NAS verifiziert: Dateien
identisch übertragen, Redeploy erfolgreich, /api/health grün, Daten unverändert
(2451 Tiere, 965 Würfe). CLAUDE.md hält beide Stolperfallen fest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dotnet tool update --global installiert dotnet-ef nach ~/.dotnet/tools,
aber der Runner-Container hat dieses Verzeichnis nicht im PATH. Jeder
run:-Step startet eine neue Shell -> der naechste Step (dotnet ef ...)
findet 'dotnet-ef' nicht (exitcode 1, Job rot seit DB-3).
Fix: 'echo ... >> $GITHUB_PATH' nach dem tool install; Gitea/GitHub Actions
liest diese Datei zwischen Steps und persistiert den PATH-Eintrag fuer alle
Folge-Steps in diesem Job.
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
'tool install --global' schlug ab dem 2. Lauf mit 'already installed' fehl (Tools persistieren auf
dem self-hosted Runner) → Backend-Job rot seit DB-3, noch VOR dem Drift-Check. 'tool update' ist
installiert-oder-aktualisiert = idempotent.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
dotnet ef interpretiert -c als --context, daher 'No DbContext named Release was found' →
Backend-Tests-Job rot seit DB-3. Korrekt: --configuration Release. Lokal verifiziert:
Release-Build + --no-build --configuration Release → 'No changes'. Tests 140/140.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nach dem Build-Schritt in test-backend: dotnet-ef 10.0.* global installieren,
dann `dotnet ef migrations has-pending-model-changes` ausführen. Schlaegt fehl
wenn Code-Änderungen an Entities/OnModelCreating keine passende Migration haben.
Fängt genau den Drift, den der SQLite-EnsureCreated-Testhost nicht sieht.
deploy/truenas/compose.yaml:
- 4 services: db (postgres:17), api (.NET), frontend (nginx), backup sidecar
- Named volumes as NAS bind-mounts (paths configured in .env)
- Healthchecks: db pg_isready, api /health, frontend waits on api
- ANTHROPIC_API_KEY placeholder for FEAT-12a AI stub
deploy/truenas/.env.example: POSTGRES_PASSWORD, PORT, REGISTRY, dataset paths
deploy/truenas/scripts/:
- entrypoint.sh: installs daily 03:00 cron, starts crond in foreground
- backup.sh: pg_dump -> .sql + tar czf photos -> .tar.gz + rotation
- restore.sh: psql < dump + tar xzf photos; confirmation prompt (-f to skip)
Predecessor logic (commit 6a37f9e) translated from PowerShell to POSIX sh
for Alpine containers. Same pg_dump/restore semantics, same KEEP_DAYS rotation.
.gitea/workflows/ci.yml (DRAFT -- inactive until Julian confirms Actions):
dotnet test + npm test/build on push/PR to main;
docker build+push to Gitea registry on main push only
docs/ops.md:
German ops guide -- architecture diagram, first-install checklist,
start/stop/update commands, backup runbook (manual + auto), ZFS-snapshot
layering strategy, CI activation steps, open questions, troubleshooting table
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
