DDI/docs/adr/0003-git-host-gitea-actions.md

0003 – Git-Host Gitea und Gitea Actions

• Status: Akzeptiert
• Datum: 2026-10-12

Kontext

Der Brief vermutet anhand des Pfadschemas beug.k/DDI Gitea oder Forgejo. CI und Release-Artefakte müssen zum tatsächlichen Host passen.

Prüfung (2026-10-12)

• GET https://git.beugsiud.de/api/v1/version → {"version":"1.27.2"} (Gitea-API vorhanden).
• GET https://git.beugsiud.de/api/forgejo/v1/version → 404, also kein Forgejo.
• GET https://git.beugsiud.de/api/v4/version → 404, also kein GitLab.
• GET https://git.beugsiud.de/api/v1/repos/beug.k/DDI → Repository existiert und ist öffentlich lesbar.

Ergebnis: Gitea 1.27.2.

Entscheidung

• CI unter .gitea/workflows/ in GitHub-Actions-kompatibler Syntax.
• Externe Actions (actions/checkout, actions/setup-go, actions/setup-node) sind auf Commit-SHA gepinnt; die Version steht als Kommentar dahinter.
• Release-Workflow bei Tag v*: make release baut die Artefakte, scripts/release-upload.sh legt per Gitea-API (POST /api/v1/repos/{owner}/{repo}/releases, POST …/releases/{id}/assets) das Release an und lädt die Dateien hoch.
• Download-URL der Artefakte (Gitea-Schema): https://git.beugsiud.de/beug.k/DDI/releases/download/<TAG>/<DATEI>; Rohdatei-URL: https://git.beugsiud.de/beug.k/DDI/raw/branch/main/<PFAD>. Beide URLs werden in M6 mit einem echten Release getestet.

Nachträge

• 2026-10-12: Mit dem Release v0.1.0 erprobt. Der Release-Workflow legt das Release mit dem automatischen Job-Token an und lädt die Artefakte hoch. Der Download über https://git.beugsiud.de/beug.k/DDI/releases/download/v0.1.0/<DATEI> funktioniert ohne Anmeldung, die Prüfsummen stimmen. RELEASE_TOKEN ist auf dieser Instanz nicht nötig.

Konsequenzen und Voraussetzungen

• Der Gitea-Runner (act_runner) braucht ein Image mit Node.js (die gepinnten Actions laufen auf Node 24) und für den Compose-Smoke-Test Zugriff auf einen Docker-Daemon (Docker-CLI mit Compose-Plugin im Job-Image, Socket in den Job-Container gereicht). Jobs, die Docker brauchen, sind eigenständig, damit ein Runner ohne Docker die übrigen Prüfungen trotzdem ausführt.
• Weil der Docker-Daemon in dieser Konstellation das Dateisystem des Job-Containers nicht sieht, nutzt die Entwicklungsumgebung keine Bind-Mounts für Konfigurationsdateien. Die Dateien werden per Dockerfile in die Images kopiert, der Build-Kontext läuft über die Docker-API.
• Der Release-Upload nutzt das automatisch bereitgestellte Job-Token. Reichen dessen Rechte auf der Instanz nicht, wird ein Secret RELEASE_TOKEN verwendet (siehe docs/OPERATIONS.md, ab M6).