[MEDIUM] CI: Build/Publish scheitert am Artifact-Schritt, npm-Publish zielt auf falsche Registry #1

New Issue

2026-07-30T16:14:59Z

sorb commented

2026-07-30 16:14:59 +00:00

Zwei zusammenhaengende CI-Probleme, entdeckt 2026-07-30 nach einem Push auf diesen
Fork - der zuvor registrierte Gitea-Actions-Runner (builder-1, laeuft auf CFGMON, siehe
Backlogs-Repo hosts/cfgmon.md CFGMON-02) hat dadurch erstmals mehrere geerbte
Upstream-Workflows fuer diesen Fork ausgefuehrt.

1. Build-/Publish-Workflows scheitern am Artifact-Schritt

build.yaml und publish-embedded-packages.yaml schlagen wiederholt am selben Punkt
fehl: Checkout/Dependencies/teils sogar der Build-Schritt selbst ("Build Element Call")
laufen durch, aber "Upload Artifact" bzw. "📥 Download built element-call
artifact" scheitern.

Nicht verifizierte Hypothese: der Runner begrenzt Job-Container auf 2,2 GiB/1,5 CPU
(thread-net-git, runner/config.yaml - Kommentar dort: "2 parallele Electron-Builds
... enden im OOM"). Fuer einen Element-Call-Build knapp bemessen. Kein OOM-Log direkt
eingesehen, daher als Hypothese markiert, nicht als Befund. Vor einer Aenderung des Limits:
Runner-Job-Logs (nicht nur die Gitea-UI) auf OOM-Kill pruefen.

2. npm-Publish zielt auf die falsche Registry

.github/workflows/publish-embedded-packages.yaml verwendet weiterhin
registry-url: "https://registry.npmjs.org" und den @element-hq-Scope (Upstream-
Konfiguration). Das Embedded-Package wird tatsaechlich unter @sorb/threadnet-call-embedded
zur Gitea-npm-Registry veroeffentlicht (https://rohana.axion1337.de/api/packages/sorb/npm/)

aktuell manuell/lokal ueber eine nicht committete .npmrc mit Zugangsdaten im
Arbeitsverzeichnis.

Vorschlag: Workflow auf die Gitea-Registry/den @sorb-Scope umstellen, Token als
Gitea-Actions-Secret hinterlegen (nicht SOPS - dafuer gibt es hier keinen etablierten
Mechanismus, Gitea Actions verschluesselt Secrets bereits selbst).

Verwandt: gitops#33
(urspruengliche, mittlerweile korrigierte Diskussion zum fehlenden Runner).

Zwei zusammenhaengende CI-Probleme, entdeckt 2026-07-30 nach einem Push auf diesen Fork - der zuvor registrierte Gitea-Actions-Runner (`builder-1`, laeuft auf CFGMON, siehe Backlogs-Repo `hosts/cfgmon.md` CFGMON-02) hat dadurch erstmals mehrere geerbte Upstream-Workflows fuer diesen Fork ausgefuehrt. ## 1. Build-/Publish-Workflows scheitern am Artifact-Schritt `build.yaml` und `publish-embedded-packages.yaml` schlagen wiederholt am selben Punkt fehl: Checkout/Dependencies/teils sogar der Build-Schritt selbst ("Build Element Call") laufen durch, aber **"Upload Artifact"** bzw. **"📥 Download built element-call artifact"** scheitern. **Nicht verifizierte Hypothese**: der Runner begrenzt Job-Container auf 2,2 GiB/1,5 CPU (`thread-net-git`, `runner/config.yaml` - Kommentar dort: "2 parallele Electron-Builds ... enden im OOM"). Fuer einen Element-Call-Build knapp bemessen. Kein OOM-Log direkt eingesehen, daher als Hypothese markiert, nicht als Befund. Vor einer Aenderung des Limits: Runner-Job-Logs (nicht nur die Gitea-UI) auf OOM-Kill pruefen. ## 2. npm-Publish zielt auf die falsche Registry `.github/workflows/publish-embedded-packages.yaml` verwendet weiterhin `registry-url: "https://registry.npmjs.org"` und den `@element-hq`-Scope (Upstream- Konfiguration). Das Embedded-Package wird tatsaechlich unter `@sorb/threadnet-call-embedded` zur Gitea-npm-Registry veroeffentlicht (`https://rohana.axion1337.de/api/packages/sorb/npm/`) - aktuell manuell/lokal ueber eine nicht committete `.npmrc` mit Zugangsdaten im Arbeitsverzeichnis. **Vorschlag**: Workflow auf die Gitea-Registry/den `@sorb`-Scope umstellen, Token als Gitea-Actions-Secret hinterlegen (nicht SOPS - dafuer gibt es hier keinen etablierten Mechanismus, Gitea Actions verschluesselt Secrets bereits selbst). Verwandt: [gitops#33](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/33) (urspruengliche, mittlerweile korrigierte Diskussion zum fehlenden Runner).

sorb referenced this issue from sorb/axion1337.chat-gitops

2026-07-30 16:15:10 +00:00

[LOW] Gitea Actions Workflows existieren, laufen aber nie (kein Runner) #33

sorb commented

2026-07-31 11:10:18 +00:00

Update 2026-07-31: Die CI-Strategie hat sich geaendert - Build-CI laeuft jetzt im Homelab-GitLab (siehe ThreadNet-Web#2, dort ist die Pipeline seit heute komplett gruen). Fuer dieses Repo heisst das: die fehlschlagenden Gitea-Actions-Workflows werden nicht mehr repariert, sondern im Zuge des Gitea-CI-Rueckbaus entfernt (Backlogs CFGMON-11) und durch eine .gitlab-ci.yml ersetzt. Punkt 1 (Artifact-Fehlschlaege/Ressourcenlimit) ist damit hinfaellig - der Lab-Runner hat genug RAM (nachgewiesen beim Element-Web-Build). Punkt 2 (npm-Publish-Ziel) bleibt die offene Entscheidung: Gitea-npm-Registry behalten (dann neuer Push-Token als GitLab-CI-Variable) oder GitLab-Package-Registry. Danach .gitlab-ci.yml fuer dieses Repo analog ThreadNet-Web.

sorb commented

2026-07-31 16:06:34 +00:00

Stand 2026-08-01 - CI steht, Build verifiziert gruen:

.gitlab-ci.yml im Repo (git.lab kanonisch, Commit 6260cc4): build_embedded
(laeuft bei relevanten Pfad-Aenderungen + v*-Tags, Pipeline 106 gruen, dist als
Artifact) und publish_npm (manuell).
Registry-Entscheidung final, evidenzbasiert: @sorb/threadnet-call-embedded ist
pnpm-Dependency von ThreadNet-Webs apps/web, der Lockfile pinnt die Tarball-URL auf
die rohana-npm-Registry - sie bleibt dort (Umzug waere Lockfile-Churn ohne Nutzen).
Der alte manuelle Publish-Weg (lokale untracked .npmrc mit Klartext-Token) ist
damit obsolet - Token-Rotation + Loeschung siehe Backlogs CFGMON-11.

Verbleibender Schritt (User, ~2 min): In GitLab (Gruppe axion1337.chat -> Settings ->
CI/CD -> Variables) GITEA_NPM_TOKEN anlegen (neuer Gitea-Token, Scope
write:package, masked). Danach ist publish_npm einsatzbereit; erster manueller
Publish-Lauf validiert den Pfad, dann kann dieses Issue zu.

**Stand 2026-08-01 - CI steht, Build verifiziert gruen:** - `.gitlab-ci.yml` im Repo (git.lab kanonisch, Commit `6260cc4`): `build_embedded` (laeuft bei relevanten Pfad-Aenderungen + v*-Tags, Pipeline 106 gruen, dist als Artifact) und `publish_npm` (manuell). - **Registry-Entscheidung final, evidenzbasiert**: `@sorb/threadnet-call-embedded` ist pnpm-Dependency von ThreadNet-Webs `apps/web`, der Lockfile pinnt die Tarball-URL auf die rohana-npm-Registry - sie bleibt dort (Umzug waere Lockfile-Churn ohne Nutzen). - Der alte manuelle Publish-Weg (lokale untracked `.npmrc` mit Klartext-Token) ist damit obsolet - Token-Rotation + Loeschung siehe Backlogs CFGMON-11. **Verbleibender Schritt (User, ~2 min)**: In GitLab (Gruppe axion1337.chat -> Settings -> CI/CD -> Variables) `GITEA_NPM_TOKEN` anlegen (neuer Gitea-Token, Scope `write:package`, masked). Danach ist `publish_npm` einsatzbereit; erster manueller Publish-Lauf validiert den Pfad, dann kann dieses Issue zu.

sorb commented

2026-07-31 20:23:33 +00:00

Erledigt (2026-07-31, ~22:23 lokal): Der npm-Publish läuft jetzt vollständig über die Lab-CI.

build_embedded + publish_npm (Pipeline 115, git.lab) beide grün; 0.19.2-threadnet.6 liegt in der rohana-npm-Registry, dist-tags.latest zeigt darauf — per API verifiziert.
Auth über die maskierte Gruppen-Variable GITEA_NPM_TOKEN (neuer least-privilege-Token gitlab-ci-npm, nur write:package). Der alte lokale Klartext-.npmrc-Weg ist tot: Token rotiert, Datei gelöscht.
Zwei Stolpersteine auf dem Weg, beide gefixt: der Job wartete auf Branch main statt livekit (livekit ist jetzt zusätzlich protected, sonst kommt die maskierte Variable nicht an), und npm verlangt bei Prerelease-Versionen ein explizites --tag latest.
Registry-Entscheidung bleibt wie dokumentiert: Package bleibt auf rohana, solange ThreadNet-Webs pnpm-lock.yaml die Tarball-URL dorthin pinnt.

Damit ist der komplette CI-Weg dieses Forks im Lab: Bauen bei relevanten Pushes, Publishen als bewusster manueller Akt.

**Erledigt** (2026-07-31, ~22:23 lokal): Der npm-Publish läuft jetzt vollständig über die Lab-CI. - `build_embedded` + `publish_npm` (Pipeline 115, git.lab) beide grün; `0.19.2-threadnet.6` liegt in der rohana-npm-Registry, `dist-tags.latest` zeigt darauf — per API verifiziert. - Auth über die maskierte Gruppen-Variable `GITEA_NPM_TOKEN` (neuer least-privilege-Token `gitlab-ci-npm`, nur `write:package`). Der alte lokale Klartext-`.npmrc`-Weg ist tot: Token rotiert, Datei gelöscht. - Zwei Stolpersteine auf dem Weg, beide gefixt: der Job wartete auf Branch `main` statt `livekit` (livekit ist jetzt zusätzlich protected, sonst kommt die maskierte Variable nicht an), und npm verlangt bei Prerelease-Versionen ein explizites `--tag latest`. - Registry-Entscheidung bleibt wie dokumentiert: Package bleibt auf rohana, solange ThreadNet-Webs `pnpm-lock.yaml` die Tarball-URL dorthin pinnt. Damit ist der komplette CI-Weg dieses Forks im Lab: Bauen bei relevanten Pushes, Publishen als bewusster manueller Akt.

sorb closed this issue

2026-07-31 20:23:33 +00:00

sorb commented

2026-08-01 14:25:44 +00:00

Migriert nach git.lab: axion1337.chat/threadnet-call#1 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

**Migriert nach git.lab**: [axion1337.chat/threadnet-call#1](https://git.lab/axion1337.chat/threadnet-call/-/issues/1) (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sorb/threadnet-call#1