update.sh meldet nach dem Neustart ein Event (POST /api/v1/events/system, Admin-Key).
upsertPullRequest markiert bereits vorhandene Tickets als Pull Request, damit sie den
/pulls/-Link bekommen.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Der sync-Container legt api/data/deploy-requested an, sobald die Zahl offener
PRs sinkt. deploy-webhook.py prueft dann per git fetch, ob origin/main vor dem
lokalen Stand liegt, und startet nur dann update.sh. Fallback fuer einen
verpassten Push-Webhook ohne zusaetzliche Codeberg-Verbindung.
Ausloeser waehrend eines laufenden Updates werden nicht mehr verworfen,
sondern loesen einen Folgelauf aus.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Auf dem Produktionsserver scheiterte "update.sh" an der untracked hosts.conf:
seit Issue #70 schreibt check_fds.sh diese Datei bei jedem Lauf neu, versioniert
ist nur hosts-sample.conf - in .gitignore stand sie aber (anders als
monitor-api.conf und credentials.conf) nicht.
- hosts.conf in .gitignore aufgenommen
- update.sh blockiert nur noch bei Aenderungen an versionierten Dateien und
listet sie auf; unversionierte Dateien werden nur als Hinweis geloggt, denn
der ff-only-Pull laesst sie unangetastet bzw. bricht selbst kontrolliert ab
- neuer Notausgang UPDATE_ALLOW_DIRTY=1 fuer den Fall, dass doch einmal an einer
versionierten Datei gedreht wurde
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HBVdYcfaXNq49bMdQQcZue
deploy-webhook.py laeuft auf dem Host, prueft eingehende Codeberg-Webhooks per
HMAC-Signatur (analog zu POST /api/v1/webhooks/codeberg) und stoesst bei einem
Push auf main - also nach jedem manuell gemergten PR - das bereits vorhandene
update.sh an. README_UPDATE.md dokumentiert die dafuer noetigen manuellen
Vorarbeiten auf dem Server (Checkout, Docker, systemd-Unit, Webhook-Einrichtung).
Schliesst #36
