3efa0ee423
Aenderungen an Codeberg-Issues landeten bisher erst beim naechsten Lauf des sync-Services auf dem Board (MONITOR_SYNC_INTERVAL, Default 600s). Neu meldet Codeberg jede Aenderung aktiv per Webhook, der Weg aufs Board dauert damit wenige Sekunden (Webhook -> Sync -> SSE-Push ans Frontend). POST /api/v1/webhooks/codeberg wertet den Payload bewusst nicht aus, sondern fordert nur einen regulaeren Sync an - CodebergSyncService bleibt die einzige Stelle, die Issues auf Tickets abbildet, und ein verpasster Webhook ist folgenlos, weil der periodische Lauf denselben Stand ohnehin nachholt. Der Sync passiert nicht im Request: Forgejo bricht die Zustellung nach wenigen Sekunden ab (DELIVER_TIMEOUT, Default 5s), ein Sync macht aber mehrere Requests nach codeberg.org. Der Endpunkt setzt daher nur eine Trigger-Datei im gemeinsamen ./api-Volume (Sync\SyncTrigger) und antwortet sofort mit 202; der sync-Service laeuft jetzt im Watch-Modus und greift sie im Sekundentakt auf. Authentifiziert wird per HMAC-SHA256 ueber den rohen Request-Body (X-Forgejo-Signature bzw. X-Gitea-Signature) - Codeberg kennt unsere API-Keys nicht. Ohne gesetztes CODEBERG_WEBHOOK_SECRET weist der Endpunkt grundsaetzlich mit 401 ab, damit ein vergessenes Secret keinen offenen Sync-Ausloeser im Internet hinterlaesst. Request traegt dafuer neu den unveraenderten rawBody. Anders als der sync-Service braucht der api-Service damit eine eingehende Freigabe in Proxy und Firewall (POST /api/v1/webhooks/codeberg). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
37 lines
2.1 KiB
Text
37 lines
2.1 KiB
Text
# Kopieren nach .env und Werte anpassen. Wird von docker-compose.yml gelesen.
|
|
|
|
# Administrator-Key zur Registrierung neuer Agenten (POST /api/v1/agents, Header X-Admin-Key)
|
|
MONITOR_ADMIN_API_KEY=change-me
|
|
|
|
# Basis-URL, unter der das Frontend (Browser!) die REST-API erreicht. Der Default passt zum
|
|
# Port-Mapping des api-Service in docker-compose.yml (8091). Wer die Ports dort aendert oder
|
|
# das System hinter einem Reverse Proxy betreibt, muss diesen Wert entsprechend nachziehen -
|
|
# z.B. https://monitor.example.org:4444/api/v1.
|
|
# Leer lassen, wenn Frontend und API unter demselben Origin ausgeliefert werden (dann wird
|
|
# die relative URL /api/v1 verwendet).
|
|
MONITOR_API_BASE=http://localhost:8091/api/v1
|
|
|
|
# Codeberg-Repo, aus dem Backlog/Done per Sync-Skript befuellt werden
|
|
CODEBERG_OWNER=fds2610
|
|
CODEBERG_REPO=monitor
|
|
# Optional: Token mit Lesezugriff, falls Rate-Limits ohne Token zu knapp sind - bei kleinem
|
|
# MONITOR_SYNC_INTERVAL (haeufigem Sync) empfehlenswert
|
|
CODEBERG_TOKEN=
|
|
|
|
# Abstand zwischen zwei periodischen Codeberg-Sync-Laeufen in Sekunden (Service "sync" in
|
|
# docker-compose.yml). Der erste Lauf passiert direkt beim Start des Services.
|
|
# Mit eingerichtetem Webhook (siehe unten) ist das nur noch das Sicherheitsnetz fuer
|
|
# verpasste Zustellungen und darf gross bleiben - Issue-Aenderungen landen dann in Sekunden
|
|
# auf dem Board, nicht erst beim naechsten Lauf.
|
|
# Speist ausserdem den rein kosmetischen Reload-Countdown im Header der Buero-Visualisierung
|
|
# (Service "web", siehe docker/nginx/default.conf.template) - der Countdown zaehlt nur mit,
|
|
# er loest selbst keinen echten Reload/Sync aus.
|
|
MONITOR_SYNC_INTERVAL=600
|
|
|
|
# Secret des Codeberg-Webhooks (Repo -> Einstellungen -> Webhooks -> Forgejo, Ziel-URL
|
|
# <oeffentliche-api-url>/api/v1/webhooks/codeberg, Events "Issues" und "Issue-Label").
|
|
# Codeberg signiert damit jeden Payload; ohne gesetztes Secret weist die API den Endpunkt
|
|
# grundsaetzlich mit 401 ab. Erzeugen z.B. mit: openssl rand -hex 32
|
|
# Der Endpunkt ist der einzige, den Codeberg von aussen erreichen muss - Proxy und Firewall
|
|
# muessen POST /api/v1/webhooks/codeberg also aus dem Internet durchlassen.
|
|
CODEBERG_WEBHOOK_SECRET=
|