cfgmon: Runner-Praemisse korrigiert (CFGMON-02/-08/-10)

Frueherer Stand ging von "kein Runner registriert, Standort offen" aus
(CFGMON-08). Beides falsch: builder-1 laeuft bereits auf CFGMON, als Teil
von thread-net-git's rework/stack-Branch (noch nicht in main gemergt, aber
produktiv aktiv, mit gezielt fuer Electron-Builds eingerichteten Labels).
CFGMON-02 entsprechend aktualisiert (in Arbeit statt offen, Merge-Rueckstand
als eigener Punkt benannt), CFGMON-08 nach Erledigt verschoben mit klarer
Korrektur-Notiz statt geloescht. Neuer Punkt CFGMON-10 fuer die dabei
entdeckten threadnet-call-CI-Fehlschlaege (Artifact-Schritt), verlinkt zum
neuen Issue threadnet-call#1.

Cross-referenziert in gitops#33 (korrigiert und geschlossen), gitops#44
(geschlossen als Duplikat), ThreadNet-Web#2 (praezisiert).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

hosts/cfgmon.md

@@ -21,9 +21,10 @@ Monitoring-Stack, Gitea und der Reverse Proxy für alles Öffentliche.
 | grafana | `grafana/grafana:12.0.0` | `monitoring` | dito |
 | alloy | `grafana/alloy:v1.16.0` | `monitoring` | dito |
 | node-exporter | `prom/node-exporter:v1.9.1` | `monitoring` | dito |
-| traefik | `traefik:v3.7.9` | `thread-net-git` | **nicht versioniert**, Portainer-Stack in `/data/compose/8` |
-| gitea | `gitea/gitea:latest` | `thread-net-git` | dito |
-| cadvisor | `gcr.io/cadvisor/cadvisor:latest` | `thread-net-git` | dito |
+| traefik | `traefik:v3.7.9` | `thread-net-git` | `sorb/thread-net-git`, Branch `rework/stack` (**nicht in `main` gemergt**, aber produktiv aktiv — siehe [CFGMON-02](#cfgmon-02--traefik-gitea-cadvisor-und-runner-werden-unter-iac-gebracht)) |
+| gitea | `gitea/gitea:1.27.0` | `thread-net-git` | dito, gepinnt (war `:latest`) |
+| cadvisor | `gcr.io/cadvisor/cadvisor:v0.49.1` | `thread-net-git` | dito, gepinnt (war `:latest`) |
+| runner | `gitea/act_runner:0.6.1` | `thread-net-git` | dito, Container `gitea-runner`, siehe CFGMON-02 |
 | portainer_agent | `portainer/agent:2.27.5` | — | standalone, kein Compose |
 
 Prometheus-Jobs: `operating_prometheus`, `operating_node-exporter`,
@@ -101,30 +102,34 @@ still.
 
 ---
 
-## CFGMON-02 — Traefik, Gitea und cAdvisor sind nicht versioniert
+## CFGMON-02 — Traefik, Gitea, cAdvisor und Runner werden unter IaC gebracht
 
-**Status:** offen
+**Status:** in Arbeit (Stand 2026-07-30)
 
-Die drei laufen im Compose-Projekt `thread-net-git` aus `/data/compose/8`, einem
-**von Portainer verwalteten Stack**. Es gibt kein Repo dazu. Betroffen ist damit
-ausgerechnet die Infrastruktur, an der alles andere hängt:
+Liefen ursprünglich im Compose-Projekt `thread-net-git` aus `/data/compose/8`, einem
+**von Portainer verwalteten Stack** ohne Repo dazu. Betroffen war damit ausgerechnet die
+Infrastruktur, an der alles andere hängt (Traefik = einzige Stelle für Entrypoints/ACME/
+Zertifikatsspeicher, Gitea = hostet die Repos, die die Infrastruktur beschreiben,
+cAdvisor = Abhängigkeit des Monitoring-Stacks).
 
-- **Traefik** — die einzige Stelle, an der Entrypoints, ACME-Resolver und
-  Zertifikatsspeicher definiert sind. Die Resolver-Namen aus dieser Datei sind der
-  Grund, warum ein Label `certresolver=le` monatelang ins Leere zeigte.
-- **Gitea** — hostet die Repos, in denen die Infrastruktur beschrieben wird. Das ist
-  ein Bootstrapping-Problem: die Definition von Gitea könnte in Gitea liegen, wäre
-  bei einem Ausfall aber genau dann nicht erreichbar, wenn man sie braucht.
-- **cAdvisor** — wird von Prometheus als `operating_cadvisor` gescrapt, ist also eine
-  Abhängigkeit des Monitoring-Stacks, die selbst außerhalb der IaC liegt.
+**Export existiert bereits**: `sorb/thread-net-git`, Branch `rework/stack` (6 Commits) —
+`:latest`-Tags gepinnt (Gitea `1.27.0`, cAdvisor `v0.49.1`), Projektname `thread-net-git`
+beibehalten (Volume-Kontinuität), README mit Betriebsregeln ("nie wieder über Portainer
+anfassen", Volume-Namen, Downgrade-Verbot für Gitea), nächtliches nicht-rotierendes
+Backup-Script. **Zusätzlich neu**: ein `runner`-Service
+(`gitea/act_runner:0.6.1`, Container `gitea-runner`, Labels `ubuntu-latest`/`linux-build`/
+`win-wine` — die letzten beiden gezielt für Electron-Builds, `electronuserland/builder`-
+Images) — das war ursprünglich [CFGMON-08](#cfgmon-08) als offene Frage gelistet, ist aber
+längst umgesetzt, siehe dort.
 
-**Nächster Schritt:** Stack-Definition aus Portainer exportieren
-(`/data/compose/8/docker-compose.yml` plus zugehörige Files), in ein Repo überführen
-und dabei die `:latest`-Tags pinnen — `gitea/gitea:latest` und
-`cadvisor:latest` machen jeden Pull zu einem unkontrollierten Update. Beim Übertragen
-denselben Projektnamen `thread-net-git` beibehalten, sonst legt Compose neue leere
-Volumes an. Für Gitea zusätzlich klären, wo die Definition liegen soll, damit sie
-bei einem Gitea-Ausfall erreichbar bleibt.
+**Offen bleibt**: der Branch ist **nicht in `main` gemergt**, obwohl er nachweislich
+produktiv läuft (der Runner darauf verarbeitet bereits echte Jobs, siehe CFGMON-10). Damit
+ist der aktuelle Live-Stand nur über den Branch nachvollziehbar, nicht über die
+Standardansicht des Repos — sollte gemergt werden, sobald das Backup-Script (siehe README
+auf dem Branch) einmal verifiziert lief.
+
+**Nächster Schritt:** `rework/stack` nach `main` mergen (Entscheidung/Ausführung beim
+Nutzer, nicht automatisiert), danach diesen Punkt auf `erledigt` setzen.
 
 ---
 
@@ -179,34 +184,6 @@ sauberer, weil dafür kein Admin-Passwort nötig ist.
 
 ---
 
-## CFGMON-08 — Kein Gitea-Actions-Runner registriert, Standort noch offen
-
-**Status:** offen
-
-`gitea.rohana.axion1337.de` (dieser Host) hostet mehrere Repos mit `.gitea/workflows/`
-(u. a. `axion1337.chat-gitops`, `ThreadNet-Web`), aber es läuft **kein Runner** — Workflows
-existieren, greifen aber nie. Tracking der eigentlichen Notwendigkeit (drei Baustellen
-hängen daran: Web-/Desktop-Build-CI, Electron-Automatisierung, npm-Publish für
-`threadnet-call`) läuft zentral in
-[gitops#33](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/33) — hier nur
-die **Standort-Frage**, die noch nicht entschieden ist:
-
-- **Auf CFGMON** (neben Gitea selbst): kürzeste Wege zu Gitea, aber dieser Host hat laut
-  [CFGMON-02](#cfgmon-02--traefik-gitea-und-cadvisor-sind-nicht-versioniert) ohnehin schon
-  unversionierte Infrastruktur - ein weiterer nicht-deklarativer Baustein wäre ungünstig,
-  außer der Runner wird von Anfang an sauber (IaC) aufgesetzt.
-- **Auf dem k3s/Matrix-Cluster** (siehe [matrix](matrix.md)): passt zum GitOps-Modell dort
-  (alles deklarativ), Runner-Pod bräuchte aber Netzzugriff zu Gitea auf CFGMON - existiert
-  bereits privat (`10.0.0.2` ↔ `10.0.0.3`).
-- **Secret-Handling für CI-Tokens** (z. B. der npm-Publish-Token für `threadnet-call`):
-  unabhängig vom Standort über Gitea Actions' eigene Secrets-Funktion (Repo-/Org-Settings),
-  nicht SOPS - siehe Begründung in gitops#33.
-
-**Nächster Schritt:** Standort entscheiden, dann Runner registrieren, dann #33 und die
-verlinkten Issues (ThreadNet-Web#2, gitops#44) abarbeiten.
-
----
-
 ## CFGMON-09 — Gitea-Backups off-host in die Storage Box (eigenes Borg-Repo)
 
 **Status:** offen — bewusst zurückgestellt am 2026-07-30
@@ -243,6 +220,30 @@ 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
+
+**Status:** offen
+
+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.
+
+**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.
+
+**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).
+
+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).
+
 ---
 
 ## Erledigt
@@ -276,3 +277,13 @@ zurück zu 2025, keine aktuellen Daten.
 
 Behoben durch ein `alloy_data`-Volume, Commit `edac97e`. Verifiziert: Positions
 überleben `--force-recreate`, zweiter Recreate erzeugt 0 Fehler.
+
+### CFGMON-08 — Kein Gitea-Actions-Runner registriert, Standort noch offen · erledigt 2026-07-30
+
+**Korrektur einer falschen Prämisse**: der Eintrag ging davon aus, dass gar kein Runner
+existiert und wo einer laufen sollte, noch offen sei. Beides falsch — ein Runner
+(`builder-1`) läuft bereits, auf CFGMON, als Teil von `thread-net-git`s `rework/stack`-
+Branch, mit gezielt für Electron-Builds eingerichteten Labels. Details siehe
+[CFGMON-02](#cfgmon-02--traefik-gitea-cadvisor-und-runner-werden-unter-iac-gebracht) — hier
+nicht dupliziert. [gitops#33](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/33)
+(dieselbe falsche Prämisse) entsprechend korrigiert/geschlossen.