# Einrichtung in Gitea

1. Repository `VULN/status` mit Branch `main` erstellen und alle Dateien dieses Pakets (einschließlich `.gitea/workflows/`) hochladen.
2. `sources.json` bearbeiten: Repository-Namen und Workflow-Dateinamen (z. B. `sync.yml`) müssen wirklich existieren. Nicht vorhandene Quellen löschen. `max_age_hours` pro Quelle anpassbar.
3. Einen Gitea Personal Access Token mit **Lesezugriff auf Actions aller überwachten Repositories** sowie **Schreibzugriff auf Code im Repository `VULN/status`** erstellen. Bei privaten Repositories müssen passende Zugriffsrechte bestehen. In `VULN/status` unter **Settings → Actions → Secrets** als `STATUS_API_TOKEN` speichern.
4. Dem gewünschten Docker-Runner Label `status:docker://python:3.12-bookworm` zuweisen (z. B. `GITEA_RUNNER_LABELS` um `,status:docker://python:3.12-bookworm` erweitern) und Runner neu starten. Damit laufen die Status-Jobs im Python-Container.
5. Actions für `VULN/status` aktivieren, Workflow `Vulnerability Status Dashboard` manuell starten. Danach alle 15 Minuten automatischer Lauf.
6. README unter `VULN/status` anschauen.

## Wichtige Hinweise

- Der API-Endpunkt ist `/api/v1/repos/{owner}/{repo}/actions/workflows/{workflow}/runs`.
- Der Job lädt das Skript über die Gitea-Contents-API; `actions/checkout` ist nicht nötig.
- Der Token ist ein Secret, niemals in die Repository-Dateien schreiben.
- Lege `STATUS_API_TOKEN` mit minimal nötigen Rechten an. Die Schreibrechte auf `VULN/status` sind für den README-Commit nötig.
- Der Workflow verwendet `gitea.server_url` als Gitea-Basis-URL. Bei Reverse-Proxy-Installationen auf korrekte `ROOT_URL` achten.
- Der Status prüft den letzten Workflow pro Quelle und den letzten erfolgreichen Lauf. Ein alter Erfolg gilt als überfällig.
- Bei API-Fehlern wird eine Fehlermeldung im Dashboard angezeigt und der Aktualisierungsjob schlägt fehl.
- Die Ausführung muss Zugang zur Gitea-API haben und DNS/TLS korrekt auflösen.