sorb/ThreadNet-Web
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 4 Wiki Activity

[MEDIUM] CI/CD deaktiviert + Build-Job checkt Upstream statt Fork aus #2

New Issue
Closed
opened 2026-07-29 18:20:34 +00:00 by sorb · 3 comments
sorb commented 2026-07-29 18:20:34 +00:00
Owner
Copy Link
Copy Source

Es gibt aktuell keinen funktionierenden CI/CD-Prozess fuer diesen Fork - weder fuer
Tests noch fuer Web- oder Desktop-Builds.

Update 2026-07-30: ein Gitea-Actions-Runner (builder-1) ist mittlerweile registriert
und aktiv (laeuft auf CFGMON, Details: Backlogs-Repo hosts/cfgmon.md CFGMON-02) - mit
Labels (linux-build/win-wine, electronuserland/builder-Images), die gezielt fuer
Electron-Builds eingerichtet wurden. "Kein Runner" ist damit kein Blocker mehr. Die
beiden folgenden Punkte sind aber weiterhin unveraendert real (heute per grep bestaetigt):

Befund:

  • Dieses Repo hat Gitea Actions in den Repo-Settings deaktiviert
    (has_actions: false) - dadurch laufen die Workflows trotz vorhandenem Runner nie,
    unabhaengig vom Inhalt der Workflow-Dateien. Einfacher Schalter, kein Infrastrukturthema.
  • .github/workflows/build-and-test.yaml (Zeilen 63, 140, 267) und
    .github/workflows/build_desktop_prepare.yaml (Zeile 59) checken weiterhin explizit
    repository: element-hq/element-web aus - das Upstream-Repo, nicht diesen Fork. Der
    prepare_ed-Job (build_desktop_prepare.yaml, webapp-artifact: webapp) wuerde
    zwar grundsaetzlich den selbst gebauten apps/web-Output inkl. Fork-Anpassungen
    uebernehmen, aber nur wenn der vorgelagerte Checkout tatsaechlich den Fork baut.

Konsequenz: jede neue Fork-Aenderung (aktuell z.B. die client-seitigen
ClamAV-Scan-Patches) landet nur im manuell gebauten Produktiv-Container/-Release, nicht
automatisch in CI. Die aktuell verfuegbare Electron-Version (Release
desktop-v1.12.17-clientscan) bleibt ein manueller Einmal-Build.

Vorschlag:

  1. Actions fuer dieses Repo in den Settings aktivieren.
  2. Die 4 hartcodierten element-hq/element-web-Checkouts auf
    repository: ${{ github.repository }} (bzw. den Fork-Namen) umstellen.
  3. Web-Container-Image-Build (aktuell manuell via docker build + docker push)
    ebenfalls automatisieren.
  4. Bis dahin: dokumentierten, wiederholbaren manuellen Build-Prozess als Zwischenloesung
    festhalten (teilweise schon in docs/deployment-guides/06-moderation-content-scanning.md
    im gitops-Repo beschrieben).
Es gibt aktuell keinen funktionierenden CI/CD-Prozess fuer diesen Fork - weder fuer Tests noch fuer Web- oder Desktop-Builds. **Update 2026-07-30**: ein Gitea-Actions-Runner (`builder-1`) ist mittlerweile registriert und aktiv (laeuft auf CFGMON, Details: Backlogs-Repo `hosts/cfgmon.md` CFGMON-02) - mit Labels (`linux-build`/`win-wine`, electronuserland/builder-Images), die gezielt fuer Electron-Builds eingerichtet wurden. "Kein Runner" ist damit **kein Blocker mehr**. Die beiden folgenden Punkte sind aber weiterhin unveraendert real (heute per grep bestaetigt): **Befund**: - Dieses Repo hat Gitea Actions in den Repo-Settings **deaktiviert** (`has_actions: false`) - dadurch laufen die Workflows trotz vorhandenem Runner nie, unabhaengig vom Inhalt der Workflow-Dateien. Einfacher Schalter, kein Infrastrukturthema. - `.github/workflows/build-and-test.yaml` (Zeilen 63, 140, 267) und `.github/workflows/build_desktop_prepare.yaml` (Zeile 59) checken weiterhin explizit `repository: element-hq/element-web` aus - das Upstream-Repo, nicht diesen Fork. Der `prepare_ed`-Job (`build_desktop_prepare.yaml`, `webapp-artifact: webapp`) wuerde zwar grundsaetzlich den selbst gebauten `apps/web`-Output inkl. Fork-Anpassungen uebernehmen, aber nur wenn der vorgelagerte Checkout tatsaechlich den Fork baut. **Konsequenz**: jede neue Fork-Aenderung (aktuell z.B. die client-seitigen ClamAV-Scan-Patches) landet nur im manuell gebauten Produktiv-Container/-Release, nicht automatisch in CI. Die aktuell verfuegbare Electron-Version (Release `desktop-v1.12.17-clientscan`) bleibt ein manueller Einmal-Build. **Vorschlag**: 1. Actions fuer dieses Repo in den Settings aktivieren. 2. Die 4 hartcodierten `element-hq/element-web`-Checkouts auf `repository: ${{ github.repository }}` (bzw. den Fork-Namen) umstellen. 3. Web-Container-Image-Build (aktuell manuell via `docker build` + `docker push`) ebenfalls automatisieren. 4. Bis dahin: dokumentierten, wiederholbaren manuellen Build-Prozess als Zwischenloesung festhalten (teilweise schon in `docs/deployment-guides/06-moderation-content-scanning.md` im gitops-Repo beschrieben).
sorb commented 2026-07-29 22:56:42 +00:00
Author
Owner
Copy Link
Copy Source

Verwandt: die Root-Ursache (kein Gitea-Actions-Runner registriert) ist jetzt zentral als gitops#33 nachgehalten - dort auch der Querverweis auf die aehnliche threadnet-call-npm-Publish-Luecke, die vom selben Runner geloest wuerde.

Verwandt: die Root-Ursache (kein Gitea-Actions-Runner registriert) ist jetzt zentral als [gitops#33](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/33) nachgehalten - dort auch der Querverweis auf die aehnliche threadnet-call-npm-Publish-Luecke, die vom selben Runner geloest wuerde.
sorb changed title from [MEDIUM] CI/CD für Web- und Desktop-Builds fehlt (kein Runner, Build-Job checkt Upstream statt Fork aus) to [MEDIUM] CI/CD deaktiviert + Build-Job checkt Upstream statt Fork aus 2026-07-30 16:14:22 +00:00
sorb commented 2026-07-31 11:09:33 +00:00
Author
Owner
Copy Link
Copy Source

Erledigt (2026-07-31) - allerdings anders als urspruenglich geplant: die CI laeuft
jetzt im Homelab-GitLab (git.lab/axion1337.chat/ThreadNet-Web), nicht in Gitea Actions.
Hintergrund und Rueckbau-Plan der Gitea-Seite: Backlogs-Repo, hosts/cfgmon.md CFGMON-11.

Was jetzt existiert (.gitlab-ci.yml, alle Jobs live verifiziert):

  • web: Webapp-Build (frozen-lockfile statt layered.sh, 6-GB-Heap) - der Build, der auf
    dem Gitea-Runner am OOM scheiterte, laeuft im Lab sauber durch
  • docker_web: baut das kanonische apps/web/Dockerfile-Image und pusht nach
    rohana.axion1337.de/sorb/threadnet-web (Tags sha-<commit> + latest-ci) - verifiziert
    in der Registry angekommen. Deploy bleibt manueller Tag-Bump im gitops-Repo.
  • desktop_image: Build-Toolchain-Image (rust:bullseye + node, glibc-2.31-Ziel) nach rohana
  • desktop_linux: Electron-Linux-Build (deb + tar.gz als Job-Artifacts, 6-Min-Lauf) -
    seit dem ersten gruenen Lauf automatisch bei jedem Push auf main

Die 4 hartcodierten element-hq/element-web-Checkouts aus dem urspruenglichen Befund sind
ebenfalls gefixt (Commit 6a8a2bb), die Upstream-Workflow-Sammlung wurde auf 6 relevante
Dateien reduziert (Commit 170d6c3) - beides inzwischen ohnehin durch die GitLab-CI abgeloest.

Folgearbeit (separat nachgehalten): Windows-Build-Strecke (eigenes Issue folgt),
Playwright-E2E in CI, Release-Publishing aus CI.

Erledigt (2026-07-31) - allerdings anders als urspruenglich geplant: die CI laeuft jetzt im **Homelab-GitLab** (`git.lab/axion1337.chat/ThreadNet-Web`), nicht in Gitea Actions. Hintergrund und Rueckbau-Plan der Gitea-Seite: Backlogs-Repo, `hosts/cfgmon.md` CFGMON-11. **Was jetzt existiert** (`.gitlab-ci.yml`, alle Jobs live verifiziert): - `web`: Webapp-Build (frozen-lockfile statt layered.sh, 6-GB-Heap) - der Build, der auf dem Gitea-Runner am OOM scheiterte, laeuft im Lab sauber durch - `docker_web`: baut das kanonische `apps/web/Dockerfile`-Image und pusht nach `rohana.axion1337.de/sorb/threadnet-web` (Tags `sha-<commit>` + `latest-ci`) - verifiziert in der Registry angekommen. Deploy bleibt manueller Tag-Bump im gitops-Repo. - `desktop_image`: Build-Toolchain-Image (rust:bullseye + node, glibc-2.31-Ziel) nach rohana - `desktop_linux`: Electron-Linux-Build (deb + tar.gz als Job-Artifacts, 6-Min-Lauf) - seit dem ersten gruenen Lauf automatisch bei jedem Push auf main Die 4 hartcodierten `element-hq/element-web`-Checkouts aus dem urspruenglichen Befund sind ebenfalls gefixt (Commit 6a8a2bb), die Upstream-Workflow-Sammlung wurde auf 6 relevante Dateien reduziert (Commit 170d6c3) - beides inzwischen ohnehin durch die GitLab-CI abgeloest. **Folgearbeit** (separat nachgehalten): Windows-Build-Strecke (eigenes Issue folgt), Playwright-E2E in CI, Release-Publishing aus CI.
sorb closed this issue 2026-07-31 11:09:34 +00:00
sorb commented 2026-08-01 14:25:48 +00:00
Author
Owner
Copy Link
Copy Source

Migriert nach git.lab: axion1337.chat/ThreadNet-Web#2 (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-Web#2](https://git.lab/axion1337.chat/ThreadNet-Web/-/issues/2) (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.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
sorb (ScrublordMcBad)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/ThreadNet-Web#2