Files

T

Thore Cimbal 2e2b709fd9 docs(adr): accept ADR-0015 — wiki git-storage live and verified

Wiki.js→Gitea (sorb/ThreadNetWiki) is wired and verified end-to-end (status
operational, page create/delete propagates). Move ADR-0015 to accepted with an
implementation note; mark the git-storage part of #0048 done. Remaining: the
canonize job Gitea→git.lab (needs the target repo decision).

2026-08-13 12:00:00 +00:00

3.4 KiB

Raw Blame History

type, id, status, date, supersedes, superseded_by, related

type

status

date

supersedes

superseded_by

adr

0015

accepted

2026-08-13

null

docs/issues/0048-wikijs-in-der-suite-deployen.md

docs/adr/0014-wikijs-loest-docusaurus-ab.md

docs/adr/0001-gitlab-kanonisch-push-mirror.md

0015 — Wiki.js Git-Storage: Inhalt fließt Cluster→Gitea→kanonisiert nach git.lab

Kontext

ADR-0014 macht docs-as-code zur harten Anforderung: der Wiki-Inhalt liegt in git. #0048 hielt dafür fest, ein git.lab-wiki-Repo anzulegen, „gespiegelt wie die übrigen", und es als Wiki.js-Git-Storage mit bidirektionalem Sync einzubinden.

Beim Bau (2026-08-13) zeigt sich: das ist so nicht machbar. Wiki.js läuft im Hetzner-Cluster, und der erreicht git.lab bewusst nicht — git.lab löst aus dem Pod nicht auf; nur Gitea (rohana.axion1337.de) ist per HTTPS erreichbar (verifiziert). Diese Lab-Unabhängigkeit ist Absicht (ADR-0001, ADR-0004): die Produktion darf nicht von einem Host abhängen, der nur im Lab antwortet. Der Schreiber des Inhalts sitzt also im Cluster und kann git.lab nicht beschreiben.

Optionen

A — Cluster→git.lab öffnen. Verworfen: hebelt die bewusste Lab-Unabhängigkeit aus (ADR-0001), koppelt die Produktion ans Lab.
B — Nur Gitea, kein git.lab-Kanon. Wiki.js schreibt in ein Gitea-Repo, fertig. Verworfen: der Inhalt hätte keinen kanonischen git.lab-Stand — widerspricht ADR-0001.
C — Wiki.js→Gitea, CI kanonisiert Gitea→git.lab. Wiki.js pusht in ein Gitea-Repo; ein geplanter CI-Job auf git.lab holt den Stand und schreibt ihn nach git.lab. Das ist dasselbe Muster, das für den TURN-Rotations-CronJob bereits akzeptiert ist (der einzige verbliebene Cluster-Schreibvorgang nach Gitea, siehe gitops-CLAUDE.md / canonize_rotation). Gewählt.

Entscheidung

Der Wiki.js-Git-Storage zielt auf ein Gitea-Repo (sorb/wiki) über HTTPS mit einem dedizierten Deploy-PAT. Der Inhalt wird per geplantem CI-Job Gitea→git.lab kanonisiert, analog zu canonize_rotation. Die Richtung ist gegenüber dem üblichen Push-Mirror (git.lab→Gitea) umgekehrt, weil der Schreiber im Cluster sitzt — das ist eine bewusste, dokumentierte Ausnahme zu ADR-0001, kein Regelbruch.

Konsequenzen

Leichter: reproduzierbar und lab-unabhängig; nutzt ein etabliertes Muster statt eines neuen Sonderwegs; kein Netz-Umbau am Cluster.
Schwerer: ein zweiter Cluster→Gitea-Schreibpfad, der gepflegt sein will; braucht den Kanonisierungs-Job (Vorlage canonize_rotation); ein dedizierter PAT liegt im Cluster-SOPS (eigene Rotation).
Voraussetzungen (sorb): Gitea-Repo sorb/wiki (privat) anlegen; dedizierten Deploy-PAT (write:repository) bereitstellen. Beides kann der Agent nicht selbst — der vorhandene Push-Token darf keine Repos anlegen.
Später zu klären: ob das Content-Repo unter eine Gruppe mit eigenem Mirror gehört; ob echter bidirektionaler Sync (Edits in git) gewollt ist oder push-only genügt.

Umsetzungsstand (2026-08-13)

Wiki.js→Gitea ist live und End-to-End verifiziert: Repo sorb/ThreadNetWiki (mit main initialisiert), dedizierter Deploy-PAT im SOPS-Secret wikijs-git-secret, Storage-Target operational, Seite anlegen/löschen propagiert nach Gitea. Ausstehend ist nur die zweite Hälfte — der Kanonisierungs-Job Gitea→git.lab (Vorlage canonize_rotation); dafür fehlt die Entscheidung, in welches git.lab-Repo kanonisiert wird.

3.4 KiB Raw Blame History