sorb/axion1337.chat-gitops
1
0
Fork 0
Code Issues Pull Requests Packages Projects 1 Releases 24 Wiki Activity

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

New Issue
Closed
opened 2026-07-28 14:41:09 +00:00 by sorb · 4 comments
sorb commented 2026-07-28 14:41:09 +00:00
Owner
Copy Link
Copy Source

.gitea/workflows/deploy-on-push.yml und milestone-release.yml existieren im Repo, aber es ist kein Gitea-Actions-Runner registriert (bestätigt mehrfach diese Session: gitea/api/v1/repos/.../actions/tasks liefert immer total_count: 0, Releases wurden stattdessen manuell per API erstellt). Entweder einen Runner aufsetzen (z.B. als eigener Pod im Cluster oder auf dem Host) damit die Workflows tatsächlich greifen, oder die Dateien entfernen/als vorerst inaktiv kennzeichnen, um nicht fälschlich Vertrauen in automatisierte Checks/Releases vorzutäuschen.

`.gitea/workflows/deploy-on-push.yml` und `milestone-release.yml` existieren im Repo, aber es ist kein Gitea-Actions-Runner registriert (bestätigt mehrfach diese Session: `gitea/api/v1/repos/.../actions/tasks` liefert immer `total_count: 0`, Releases wurden stattdessen manuell per API erstellt). Entweder einen Runner aufsetzen (z.B. als eigener Pod im Cluster oder auf dem Host) damit die Workflows tatsächlich greifen, oder die Dateien entfernen/als vorerst inaktiv kennzeichnen, um nicht fälschlich Vertrauen in automatisierte Checks/Releases vorzutäuschen.
sorb added the area:infrastructurepriority:low labels 2026-07-28 14:41:09 +00:00
sorb commented 2026-07-29 22:56:10 +00:00
Author
Owner
Copy Link
Copy Source

Update (2026-07-30, aus dem Doku-Audit): dieser fehlende Runner blockiert mittlerweile drei separate Stellen, alle mit derselben Ursache - ein einmal registrierter Runner sollte alle drei gleichzeitig lösen:

  • ThreadNet-Web#2 - Web-/Desktop-Build-CI, Electron zieht Fork-Aenderungen nicht automatisch
  • gitops#44 - dieselbe Electron/Desktop-Luecke, dupliziert #2, kann beim Runner-Setup mit erledigt/geschlossen werden
  • threadnet-call npm-Publish: .github/workflows/publish-embedded-packages.yaml zielt noch auf registry.npmjs.org/@element-hq-Scope statt auf die Gitea-npm-Registry (@sorb); Publish laeuft aktuell manuell/lokal ueber eine unversionierte .npmrc mit Klartext-Token im Arbeitsverzeichnis

Secret-Handling-Entscheidung: sobald ein Runner existiert, den npm-Token als Gitea-Actions-Secret (Repo/Org-Settings) hinterlegen, nicht SOPS - SOPS ist fuer in Git committete, von Flux/sops-CLI entschluesselte Secrets gedacht, nicht fuer CI-Laufzeit-Tokens. Gitea Actions verschluesselt Secrets bereits selbst und injiziert sie nur in den Workflow-Run.

Update (2026-07-30, aus dem Doku-Audit): dieser fehlende Runner blockiert mittlerweile drei separate Stellen, alle mit derselben Ursache - ein einmal registrierter Runner sollte alle drei gleichzeitig lösen: - [ThreadNet-Web#2](https://rohana.axion1337.de/sorb/ThreadNet-Web/issues/2) - Web-/Desktop-Build-CI, Electron zieht Fork-Aenderungen nicht automatisch - [gitops#44](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/44) - dieselbe Electron/Desktop-Luecke, dupliziert #2, kann beim Runner-Setup mit erledigt/geschlossen werden - **threadnet-call npm-Publish**: `.github/workflows/publish-embedded-packages.yaml` zielt noch auf `registry.npmjs.org`/`@element-hq`-Scope statt auf die Gitea-npm-Registry (`@sorb`); Publish laeuft aktuell manuell/lokal ueber eine unversionierte `.npmrc` mit Klartext-Token im Arbeitsverzeichnis **Secret-Handling-Entscheidung**: sobald ein Runner existiert, den npm-Token als Gitea-Actions-Secret (Repo/Org-Settings) hinterlegen, nicht SOPS - SOPS ist fuer in Git committete, von Flux/sops-CLI entschluesselte Secrets gedacht, nicht fuer CI-Laufzeit-Tokens. Gitea Actions verschluesselt Secrets bereits selbst und injiziert sie nur in den Workflow-Run.
sorb commented 2026-07-30 16:13:59 +00:00
Author
Owner
Copy Link
Copy Source

Korrektur (2026-07-30): die Praemisse dieses Issues (kein Runner registriert) war falsch bzw. veraltet. Ein Runner (builder-1, gitea/act_runner:0.6.1) laeuft bereits auf CFGMON, als Teil von sorb/thread-net-gits Branch rework/stack (noch nicht in main gemergt, aber produktiv aktiv - dieser Repo-Workflow deploy-on-push.yml laeuft nachweislich erfolgreich darueber). Labels umfassen linux-build/win-wine (electronuserland/builder-Images) - gezielt fuer Electron-Builds eingerichtet.

Die eigentlichen, jetzt praezisierten Restthemen sind in eigenen Issues aufgehoben statt hier gesammelt:

  • ThreadNet-Web#2 - Actions ist fuer das Repo deaktiviert (has_actions: false), zusaetzlich checken mehrere Workflow-Schritte weiterhin element-hq/element-web statt den Fork aus.
  • Neues Issue in sorb/threadnet-call (folgt) - CI-Laeufe schlagen dort am Artifact-Upload/Download-Schritt fehl, vermutlich Ressourcenlimit des Runners, nicht verifiziert.

Details/Betriebswissen zum Runner: Backlogs-Repo hosts/cfgmon.md, CFGMON-02 und CFGMON-10. Schliesse dieses Issue, die woertliche Praemisse ist erledigt.

Korrektur (2026-07-30): die Praemisse dieses Issues (kein Runner registriert) war falsch bzw. veraltet. Ein Runner (`builder-1`, `gitea/act_runner:0.6.1`) laeuft bereits auf CFGMON, als Teil von `sorb/thread-net-git`s Branch `rework/stack` (noch nicht in `main` gemergt, aber produktiv aktiv - dieser Repo-Workflow `deploy-on-push.yml` laeuft nachweislich erfolgreich darueber). Labels umfassen `linux-build`/`win-wine` (electronuserland/builder-Images) - gezielt fuer Electron-Builds eingerichtet. Die eigentlichen, jetzt praezisierten Restthemen sind in eigenen Issues aufgehoben statt hier gesammelt: - [ThreadNet-Web#2](https://rohana.axion1337.de/sorb/ThreadNet-Web/issues/2) - Actions ist fuer das Repo deaktiviert (`has_actions: false`), zusaetzlich checken mehrere Workflow-Schritte weiterhin `element-hq/element-web` statt den Fork aus. - Neues Issue in `sorb/threadnet-call` (folgt) - CI-Laeufe schlagen dort am Artifact-Upload/Download-Schritt fehl, vermutlich Ressourcenlimit des Runners, nicht verifiziert. Details/Betriebswissen zum Runner: Backlogs-Repo `hosts/cfgmon.md`, CFGMON-02 und CFGMON-10. Schliesse dieses Issue, die woertliche Praemisse ist erledigt.
sorb closed this issue 2026-07-30 16:13:59 +00:00
sorb commented 2026-07-30 16:15:10 +00:00
Author
Owner
Copy Link
Copy Source

Nachtrag: threadnet-call#1 angelegt fuer die CI-Artifact-Fehlschlaege und die npm-Registry-Fehlkonfiguration, wie oben angekuendigt.

Nachtrag: [threadnet-call#1](https://rohana.axion1337.de/sorb/threadnet-call/issues/1) angelegt fuer die CI-Artifact-Fehlschlaege und die npm-Registry-Fehlkonfiguration, wie oben angekuendigt.
sorb commented 2026-08-01 14:26:08 +00:00
Author
Owner
Copy Link
Copy Source

Migriert nach git.lab: axion1337.chat/axion1337.chat-gitops#33 (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/axion1337.chat-gitops#33](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/33) (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
Clear labels
area:authentik
Authentik Identity Provider
 area:database
Database and backups
 area:element
Element and UI
 area:infrastructure
K3S and infrastructure
 area:security
Security hardening
 priority:critical
Critical - This week
 priority:high
High - 1-2 weeks
 priority:low
Low - nice to have
 priority:medium
Medium - ~1 month
No labels area:infrastructure priority:low
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/axion1337.chat-gitops#33