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.
This commit is contained in:
Thore Cimbal
@@ -54,7 +54,7 @@ Verteilung: M1 10 · M2 23 · M4 6 · M5 2
|
||||
|
||||
_none active_
|
||||
|
||||
## ADRs (14)
|
||||
## ADRs (15)
|
||||
|
||||
| ADR | Status | Title |
|
||||
|---|---|---|
|
||||
@@ -72,6 +72,7 @@ _none active_
|
||||
| [0012](docs/adr/0012-issues-im-repo-gitlab-als-spiegel.md) | accepted | ADR-0012: Issues leben im Repo; GitLab wird deterministisch bespiegelt |
|
||||
| [0013](docs/adr/0013-gruppenregeln-kanonisch-mit-pruefung.md) | accepted | ADR-0013: Gruppenregeln kanonisch im management-Repo, Komponenten zeigen und werden geprüft |
|
||||
| [0014](docs/adr/0014-wikijs-loest-docusaurus-ab.md) | accepted | 0014 — Wiki.js löst Docusaurus ab: abgeschottete Betriebs-/Anwenderdoku, docs-as-code |
|
||||
| [0015](docs/adr/0015-wiki-git-storage-ueber-gitea-kanonisieren.md) | proposed | 0015 — Wiki.js Git-Storage: Inhalt fließt Cluster→Gitea→kanonisiert nach git.lab |
|
||||
|
||||
## Open AARs (2)
|
||||
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
type: adr
|
||||
id: "0015"
|
||||
status: proposed
|
||||
date: 2026-08-13
|
||||
supersedes: null
|
||||
superseded_by: null
|
||||
related: [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.
|
||||
@@ -38,3 +38,18 @@ Inhalts-Speicher.
|
||||
|
||||
Ersetzt den Forward-Auth-Zwischenstand auf Overmind (Guide 09, #0024). OIDC +
|
||||
Rollen kommen in #0049, Theming in #0050. Umbrella: #0046.
|
||||
|
||||
## Update 2026-08-13 — Git-Storage-Architektur korrigiert (Widerspruch)
|
||||
|
||||
Deployment, Postgres, Ingress/Cert, öffentliche Erreichbarkeit, OIDC/Rollen (#0049)
|
||||
und Theming (#0050) laufen live und reproduzierbar über den Konfig-Job.
|
||||
|
||||
**Offen ist nur der Git-Storage** — und die oben geforderte Fassung ist so **nicht
|
||||
machbar**: „`wiki`-Repo auf git.lab, gespiegelt wie die übrigen, als Storage" setzt
|
||||
voraus, dass Wiki.js git.lab erreicht. Tut es nicht — der Cluster erreicht bewusst
|
||||
nur Gitea (verifiziert 2026-08-13). Auflösung in
|
||||
[ADR-0015](../adr/0015-wiki-git-storage-ueber-gitea-kanonisieren.md): Wiki.js→Gitea
|
||||
(`sorb/wiki`), CI kanonisiert Gitea→git.lab (Muster `canonize_rotation`).
|
||||
|
||||
Voraussetzung (nur sorb): Gitea-Repo `sorb/wiki` (privat) anlegen + dedizierten
|
||||
Deploy-PAT bereitstellen. Danach verdrahtet der Agent Storage + Kanonisierungs-Job.
|
||||
|
||||
@@ -33,3 +33,22 @@ aus `git.lab/homelab/wiki` extrahiert (2026-08-12):
|
||||
|
||||
Nice-to-have (`low`), nach #0048/#0049. Assets liegen in `homelab/wiki`; beim Bau
|
||||
in das neue `wiki`-Repo kopieren.
|
||||
|
||||
## Update 2026-08-13 — Umsetzung (Teil)
|
||||
|
||||
Live und reproduzierbar über den Konfig-Job (gitops-Commit `63460e7`):
|
||||
|
||||
- **Dark-Mode als Default.**
|
||||
- **Logo** (ThreadNet `logo.png`) — als statische Datei in Wiki.js gemountet
|
||||
(`platform-branding` ConfigMap → `/_assets/img/branding/`), öffentlich ausgeliefert,
|
||||
auf der Login-Seite und eingeloggt sichtbar (kein `read:assets` für Guests nötig).
|
||||
- **Login-Hintergrund** = `alpenglow.jpg`, dieselbe Datei wie Authentik/Element
|
||||
(Erweiterung ggü. der ursprünglichen Spec, Wunsch sorb 2026-08-13) — ebenfalls lokal
|
||||
gemountet statt per externer URL verlinkt.
|
||||
|
||||
Statt der Spec-Idee „Assets ins `wiki`-Repo kopieren" liegen sie als **eine Quelle** in
|
||||
`gitops:apps/production/branding/` und werden in den Pod gemountet; später auch in
|
||||
Authentik/Element mountbar (eine Datei, keine Mehrfachpflege).
|
||||
|
||||
Noch offen: **Akzentfarbe** (`#2b6cb0`/`#63b3ed`, via injectCSS), **Favicon**, und der
|
||||
**optische Abgleich** durch sorb.
|
||||
|
||||
Reference in New Issue
Block a user