Files

T

Thore Cimbal c08611a2bd docs(adr): record wiki git-storage architecture (ADR-0015) + build progress

The cluster cannot reach git.lab (deliberate lab-independence), so #0048's
git.lab-repo-as-storage is infeasible. ADR-0015 routes Wiki.js content
cluster→Gitea→canonize to git.lab, reusing the accepted TURN-rotation pattern;
status proposed, pending sorb's ratification and two prerequisites (Gitea repo +
deploy PAT). Note the flagged contradiction on #0048 and the live theming
progress (logo, shared login background, dark default) on #0050. STATUS regen.

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

2.9 KiB

Raw Blame History

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

type

status

date

supersedes

superseded_by

adr

0015

proposed

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.

2.9 KiB Raw Blame History