diff --git a/hosts/cfgmon.md b/hosts/cfgmon.md index 0af9b6e..83e5f5e 100644 --- a/hosts/cfgmon.md +++ b/hosts/cfgmon.md @@ -189,34 +189,83 @@ Voraussetzungen, beide beim User: geprüft 2026-07-30) — Key generieren und den Public Key in der Storage Box hinterlegen (Robot-Webinterface oder einmalig per Passwort-Login). -## CFGMON-10 — threadnet-call-CI schlägt am Artifact-Schritt fehl +## CFGMON-11 — Gitea-CI-Rückbau nach GitLab-Umzug -**Status:** offen +**Status:** offen — wartet auf funktionierende GitLab-CI im Lab -Ausgelöst durch einen Push nach `threadnet-call` am 2026-07-30: der Runner (`builder-1`, -siehe CFGMON-02) verarbeitet mehrere geerbte Upstream-Workflows (`build.yaml`, -`publish-embedded-packages.yaml`, u. a.), die meisten scheitern am selben Punkt — -Checkout/Dependencies/teils sogar der Build-Schritt selbst laufen durch, aber -**"📥 Download built element-call artifact"** bzw. **"Upload Artifact"** schlagen fehl. +Entscheidung vom 2026-07-30: Build-CI/CD zieht ins Homelab-GitLab +(`git.lab/axion1337.chat`, Gruppe mit importierten Projekten angelegt; die Domain ist +**nur im Homelab auflösbar** — von CFGMON/MATRIX aus nicht erreichbar, was für den +Build-Anwendungsfall in Ordnung ist: Prod läuft bei Lab-Ausfall weiter, nur neue Builds +pausieren). Der am 2026-07-30 auf Gitea-Seite aufgebaute CI-Unterbau wird damit teilweise +überflüssig. **Erst zurückbauen, wenn die GitLab-CI nachweislich läuft.** -**Nicht verifizierte Hypothese**: das Job-Container-Limit in `runner/config.yaml` -(2,2 GiB / 1,5 CPU, Kommentar dort: "2 parallele Electron-Builds ... enden im OOM — bei -Host-Upgrade hochsetzen") ist für einen Element-Call-Build knapp. Kein OOM-Log direkt -eingesehen — reine Vermutung aus dem Fehlerbild, nicht bestätigt. +### Sicher rückbaubar -**Nächster Schritt:** Job-Logs des Runners (nicht nur die Gitea-Actions-UI) auf -OOM-Kill-Meldungen prüfen, bevor das Limit angehoben wird. Falls bestätigt: Kapazität/Limit -in `thread-net-git`s `runner/config.yaml` anpassen (Trade-off gegen den knappen -Host-Speicher, siehe CFGMON-02). +- **Actions-Toggle** `has_actions` bei `ThreadNet-Web` (am 2026-07-30 per API aktiviert) + wieder deaktivieren, ebenso bei `threadnet-call` (stoppt die fehlschlagende + Workflow-Kaskade dort). +- **`.github/workflows/` in `ThreadNet-Web`** (der kuratierte 6-Dateien-Satz) — wird durch + `.gitlab-ci.yml` ersetzt. Die Erkenntnisse aus den Läufen vom 2026-07-30 mitnehmen: + kein `layered.sh` (würde den js-sdk-Pin mit Upstream-develop überschreiben, braucht + außerdem jq), stattdessen `pnpm install --frozen-lockfile`; webpack-Build braucht + real ~4 GB Heap; `contains(needs.*.result, ...)`-Gates sind act-spezifisch kaputt. +- **Geerbte Upstream-Workflows in `threadnet-call`** (build/publish/test/translations/ + zizmor/pr-deploy) — gleiches Schicksal. +- **Runner-Identität**: wenn der Runner-Service entfällt (siehe unten), `builder-1` in + der Gitea-Admin-UI deregistrieren und `runner-data/.runner` auf dem Host entfernen. +- **Token: npm-Token in `threadnet-call`s untracked `embedded/web/.npmrc`** (Klartext im + Arbeitsverzeichnis, Fund vom 2026-07-30): revoken/rotieren. Der GitLab-CI-Publish + bekommt einen eigenen, frisch erzeugten Token als GitLab-CI-Variable — der alte + verschwindet von der Platte. -Getrackt (inkl. der separaten npm-Registry-Fehlkonfiguration) als -[threadnet-call#1](https://rohana.axion1337.de/sorb/threadnet-call/issues/1) - dort die -eigentliche Arbeit, hier nur der Host-seitige Aspekt (Runner-Ressourcenlimit). +### Entscheidungsabhängig + +- **Runner-Service in `thread-net-git` ganz entfernen?** Hängt daran, ob das gitops-Repo + seinen leichten `deploy-on-push.yml` (YAML-Validierung/Notification, läuft sauber) + behält — dann bleibt ein Minimal-Runner nötig. Bei Komplett-Entfernung als + Revert-Commit in `thread-net-git`: Compose-Service `runner`, `runner/config.yaml`, + `.env.example` (RUNNER_TOKEN), Cache-Port-Bindung 8088, `runner-data/`. +- **Registry-Ziel für `@sorb/threadnet-call-embedded`**: bleibt die Gitea-npm-Registry + (dann braucht GitLab-CI einen Push-Token dorthin — Neuanlage) oder wandert in die + GitLab-Package-Registry (dann läuft die Gitea-Package-Seite leer). +- **Container-Images bleiben in der rohana-Registry** (Flux/k8s pullt von dort — spricht + stark für Beibehalt). Gegenstück zur Token-Bilanz: GitLab-CI braucht dann einen + **neuen** Deploy-/Push-Token für die rohana-Registry (Neuanlage, kein Rückbau). + +### Explizit nicht rückbaubar + +Gitea selbst, gitops-Repo als Flux-Source, Issues/Wiki/dieses Backlogs-Repo, der +API-Token für Issue-Verwaltung, das Gitea-Backup-Script (CFGMON-09). + +Betroffene Issues (werden bei der GitLab-Migrations-Planung umformuliert): +[ThreadNet-Web#2](https://rohana.axion1337.de/sorb/ThreadNet-Web/issues/2), +[threadnet-call#1](https://rohana.axion1337.de/sorb/threadnet-call/issues/1). + +**Nächster Schritt:** GitLab-CI aufbauen (eigene Planung), erst danach die Punkte oben +abarbeiten. --- ## Erledigt +### CFGMON-10 — threadnet-call-CI schlägt am Artifact-Schritt fehl · verworfen 2026-07-30 + +Ausgelöst durch einen Push nach `threadnet-call` am 2026-07-30: der Runner (`builder-1`) +verarbeitete mehrere geerbte Upstream-Workflows, die meisten scheiterten am +Artifact-Upload/-Download-Schritt. Ursprünglich unverifizierte Hypothese: das +Job-Container-Limit (2,2 GiB / 1,5 CPU) ist zu knapp. + +**Hypothese inzwischen im Kern bestätigt** — beim parallelen ThreadNet-Web-CI-Versuch +starb der webpack-Build bei 92 % mit `FATAL ERROR: ... JavaScript heap out of memory` +(Job 3442, 2026-07-30): diese Build-Klasse braucht real ~4 GB, der Host (3,7 GiB gesamt, +ohne Swap, trägt daneben Gitea/Traefik/Monitoring) kann das strukturell nicht liefern. + +**Verworfen statt gefixt**: Limit-Anhebung/Swap wird bewusst nicht weiterverfolgt — +Build-CI zieht ins Homelab-GitLab um (siehe +[CFGMON-11](#cfgmon-11--gitea-ci-rückbau-nach-gitlab-umzug)), CFGMON bleibt bei leichten +Jobs. Issue-Seite: [threadnet-call#1](https://rohana.axion1337.de/sorb/threadnet-call/issues/1). + ### CFGMON-02 — Traefik, Gitea, cAdvisor und Runner unter IaC gebracht · erledigt 2026-07-30 Liefen ursprünglich im Compose-Projekt `thread-net-git` aus `/data/compose/8`, einem von