fix(ci): Deploy-Job repariert — kein rsync im Runner, Transfer per tar over ssh

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>

.gitea/workflows/ci.yml

@@ -160,7 +160,11 @@ jobs:
 
       - name: SSH-Client + Key einrichten
         run: |
-          command -v ssh >/dev/null 2>&1 || (apt-get update && apt-get install -y --no-install-recommends openssh-client rsync)
+          # Nur openssh-client wird gebraucht (Dateitransfer laeuft unten per "tar | ssh").
+          # FRUEHER stand hier zusaetzlich rsync im apt-Aufruf, der aber nie lief: der Guard
+          # prueft nur `ssh`, und ssh ist im Runner-Image vorhanden => "rsync: command not
+          # found" kippte den Deploy-Job (Run 107). Deshalb kein rsync mehr.
+          command -v ssh >/dev/null 2>&1 || (apt-get update && apt-get install -y --no-install-recommends openssh-client)
           install -m 700 -d ~/.ssh
           printf '%s\n' "${{ secrets.NAS_SSH_KEY }}" > ~/.ssh/id_deploy
           chmod 600 ~/.ssh/id_deploy
@@ -171,12 +175,11 @@ jobs:
           NAS="root@${{ secrets.NAS_SSH_HOST }}"
           SSH="ssh -i ~/.ssh/id_deploy -o StrictHostKeyChecking=accept-new"
           $SSH "$NAS" "mkdir -p $APP_HOME/deploy/truenas/scripts"
-          rsync -az -e "$SSH" \
-            deploy/truenas/custom-app.compose.yaml \
-            "$NAS":"$APP_HOME"/deploy/truenas/
-          rsync -az -e "$SSH" \
-            deploy/truenas/scripts/ \
-            "$NAS":"$APP_HOME"/deploy/truenas/scripts/
+          # tar-over-ssh statt rsync: rsync fehlt im Runner-Image, tar gibt es auf beiden
+          # Seiten. -o beim Entpacken => Dateien gehoeren root; Modi bleiben erhalten,
+          # die Deploy-Skripte bleiben also ausfuehrbar.
+          tar -C deploy/truenas -cf - custom-app.compose.yaml scripts \
+            | $SSH "$NAS" "tar -C $APP_HOME/deploy/truenas -xof -"
 
       - name: Custom App neu ausrollen (midclt create/redeploy + Health-Check)
         run: |

CLAUDE.md

@@ -78,6 +78,12 @@ per `tar | ssh` nach `…/gerbilmanager/photos/`.
   mounten. (Debian-Image, nicht alpine → Locale `libc/en_US.utf8` = Quell-DB.)
 - Gitea-Runner ist **containerisiert** (Label `ubuntu-latest`, kein `goldeye`, kein Host-/`midclt`-Zugriff)
   und läuft **`maxParallel=1`** (Jobs sequenziell) — daher der SSH-Weg im Deploy-Job.
+- **Auto-Deploy lief bis 2026-08-19 nie durch** (Runs 99–107 rot), zwei Ursachen: (1) die Repo-Secrets
+  `NAS_SSH_HOST`/`NAS_SSH_KEY` waren nie angelegt → `ssh root@` mit leerem Key („Could not resolve
+  hostname"); jetzt gesetzt, Deploy-Key `gitea-ci-deploy@gerbilmanager` (privat nur im Gitea-Secret,
+  Pubkey in `/root/.ssh/authorized_keys`). (2) Der Runner hat **kein `rsync`**, und der apt-Guard prüfte
+  nur `ssh` → „rsync: command not found". Dateitransfer läuft daher per **`tar | ssh`** (tar gibt es auf
+  beiden Seiten; `-xof` erhält die Modi, Skripte bleiben ausführbar).
 - CI-Run-Status notfalls aus der Gitea-DB: `docker exec -e PGPASSWORD=gitea ix-gitea-postgresdb-1
   psql -U gitea -d gitea -c "select name,status from action_run_job where run_id=(select max(id) from action_run);"`
   (`status`: 1=success, 2=failure, 4=skipped).