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> |
||
|---|---|---|
| .. | ||
| bin | ||
| docker | ||
| public | ||
| src | ||
| tests/Unit | ||
| .dockerignore | ||
| composer.json | ||
| composer.lock | ||
| phpunit.xml | ||
| README.md | ||
monitor REST-API (Phase 1)
Vanilla-PHP-REST-API (kein Framework, siehe Visualization.md Abschnitt 5) fuer Tickets,
Events, Systeme, KPIs und Agenten. Persistenz in SQLite (api/data/monitor.sqlite).
Vollstaendige Endpunkt-Dokumentation: ../API.md.
Entwicklung nur mit Docker (kein lokales PHP/Composer noetig)
Aus dem Repo-Wurzelverzeichnis:
cp .env.example .env # einmalig, MONITOR_ADMIN_API_KEY anpassen
docker compose up --build # startet die API auf http://localhost:8080
docker compose run --rm api composer test # PHPUnit inkl. Coverage
docker compose run --rm api php bin/sync-codeberg.php # Backlog/Done einmalig ziehen (Debug)
Im laufenden Betrieb wird der Codeberg-Sync nicht manuell angestossen, sondern vom
Compose-Service sync alle MONITOR_SYNC_INTERVAL Sekunden ausgefuehrt (siehe
../API.md, Abschnitt "Codeberg-Sync").
Composer-Abhaengigkeiten (nur PHPUnit als Dev-Dependency) werden beim ersten Start
automatisch im Container installiert (docker/entrypoint.sh) - auf dem Host ist
weder PHP noch Composer noch SQLite erforderlich.