chemenu/kb/entities/technologies/Gitea Actions.md

type, entity_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary

type	entity_type	tags	created	modified	related	sources	confidence	confidence_base	provenance	summary
types/entity.md	technology	ci-cd workflows automation gitea	2026-07-25	2026-09-01	Gitea Act Runner Docker Gitea MCP Server Ambient Environment Dependency CI Integration	Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30 Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31 Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31 Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31	0.90	0.90	sourced	CI/CD-Workflow-Plattform, in Gitea integriert; fuehrt YAML-Workflows ueber den Act Runner aus, samt Release-Pipeline, belegten paths-ignore-Filtern und einem nightly.yml-Drift-Check, dessen schedule-Ausloesung seit 2026-09-01 (Run 90) belegt ist

Gitea Actions

Typ: Technology (CI/CD Platform)

Beschreibung

Gitea Actions ist das CI/CD-Workflow-Automatisierungssystem, das in Gitea integriert ist. Es ermöglicht die Definition von Build-, Test- und Deployment-Pipelines als Code in YAML-Workflow-Dateien. Die Workflows werden vom Act Runner ausgeführt.

Kerndaten

• Typ: CI/CD-Workflow-Automatisierung
• Status: Aktiv (Stand 2026-07-12)
• Runner: Act Runner
• Workflow-Syntax: GitHub Actions kompatibles YAML

Architektur

Workflow-Ausführung

1. Auslöser: Push, PR, Zeitplan oder manuelle Auslösung
2. Runner-Auswahl: Basierend auf Routing-Labels (linux-docker, container-builder, k3s-deploy)
3. Job-Container: Isoliertes Bridge-Netz pro Job
4. Secret-Injektion: Runtime-Abruf aus 1Password
5. Cache: Built-in Actions Cache Server auf Port 8088

Schlüsselkomponenten

• Runner: act_runner-Docker-Container im Host-Network-Modus
• Cache Server: Built-in, zugänglich via statische IP-Konfiguration
• Job-Container: Kurzlebige Docker-Container pro Workflow-Job
• Actions: Wiederverwendbare Workflow-Komponenten

Konfiguration

Cache-Konfiguration

# In act_runner config.yaml
cache:
  enabled: true
  host: "192.0.2.10"  # static IP of ci-runner.example.net
  port: 8088

Wichtig: cache.host ist die Adresse, die Job-Container verwenden, um den Cache-Server zu erreichen, nicht die Listen-Adresse des Servers.

Workflow-Beispiel

name: Build and Deploy

on: [push]

permissions:
  packages: write  # Required for registry pushes

jobs:
  build:
    runs-on: linux-docker
    steps:
      - uses: actions/checkout@v4
      
      - name: Load secrets
        uses: 1password/load-secrets-action@v2
        with:
          vault: CI-CD
        env:
          REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}
      
      - name: Build with BuildKit
        run: |
          docker buildx create --driver remote tcp://$HOST_IP:1234
          docker buildx build --push ...

Validierte Szenarien

Szenario A: Arch-Paketbuilds

• Basis-Image: archlinux:base-devel
• Herausforderung: makepkg benötigt Root
• Lösung: Erstelle non-Root-Benutzer builder on-the-fly
• Artefakte: actions/upload-artifact@v3 (v4 nicht vollständig unterstützt)
• Hinweis: Gitea Actions v4 hat begrenzte Artefakt-Unterstützung

Szenario B: Container-Builds

• Basis-Image: debian:trixie-slim (Standard)
• Vermeidet: Alpine Linux (musl libc inkompatibel mit 1Password CLI)
• Verbindung: Dynamische IP-Erkennung via ip route | awk '/default/ { print $3 }'

Szenario C: K3s-Deployments

-Cluster

• Authentifizierung: Kubeconfig aus 1Password-Vault
• Muster: kubectl wait --for=delete pod -l ... für zuverlässige Ressourcenverwaltung

Szenario D: Test- und Release-Pipeline eines Python-Werkzeugs

• Basis-Image: debian:trixie-slim, trägt python3 3.13¹
• Erster Schritt: apt-get install nodejs, vor dem Checkout - Voraussetzung für jede JavaScript-Action, siehe Act Runner¹
• Checkout: actions/checkout@v7¹
• Release: ${{ gitea.token }} genügt für das Anlegen von Release und Tag sowie für Asset-Uploads; kein Actions-Secret mit write:repository nötig¹
• Auslöser des Release-Workflows: eine Änderung an der VERSION-Datei, siehe KB Stack Versioning

Läufe eines Workflows auf ihre Ursache prüfen

Bei einem privaten Repository lässt sich der Lauf-Zustand nicht anonym über HTTP feststellen; Gitea antwortet einem anonymen Aufrufer identisch mit 404, ob das Repository unsichtbar oder nicht vorhanden ist¹ . Läufe, ihr Ausgang und ihre Logs werden über den Gitea MCP Server gelesen.

Auslöser filtern

paths-ignore schließt Pfade von einem Workflow aus. Für die Filterlisten gelten hier drei Festlegungen, die alle Ableitungen aus Undokumentiertem vermeiden¹ :

• Keine YAML-Anker, um eine Liste zwischen zwei Workflows zu teilen. GitHubs Parser lehnt Anker ab, und für Gitea ist nicht dokumentiert, dass er sie annimmt. Die Liste steht lieber zweimal.
• Keine negierten Muster wie !**/CONTRACT.md. Gitea dokumentiert die Unterstützung negierter Filtermuster nicht.
• Die Muster scheitern offen. Alles Unvorhergesehene löst weiterhin einen Lauf aus; das ist die richtige Richtung für einen Filter, dessen Auswertung nicht bewiesen ist.

Dass die Filter greifen, ist seit 2026-08-31 beobachtet und nicht mehr angenommen. Commit f916376 war ein reiner Content-Publish - kb/index.md, kb/log.md, kb/provenance.md, acht Seiten unter kb/*/** und eine Datei unter raw/notes/, sämtlich auf der Ignore-Liste - und erzeugte zu seiner head_sha keinen einzigen Lauf² :

Commit	Inhalt	Läufe
6f54c31	Stack (1.1.0)	59
adfa220	Stack (1.1.1)	60, 61
f916376	nur kb/ und raw/	keine
40adbb7	Stack (1.2.0)	62, 63

Die Stack-Commits davor und danach erzeugten je zwei Läufe, CI und Release, weil VERSION sich bewegt hatte. Der Unterschied ist also der Filter und kein untätiger Runner; Gitea wertet diese Muster wie GitHub aus² . Der Befund steht im Kommentarkopf von .gitea/workflows/ci.yml, damit er nicht erneut für eine Annahme gehalten wird, und schloss Gitea-Issue #11² .

Als Folgewirkung bleibt die stärkste Hälfte der Begründung für den nächtlichen Drift-Check (Issue #9) stehen: Weil der Filter greift, läuft lint --fail-on-error bei einem Content-Publish tatsächlich nicht mehr. Ob dieser Gitea-Build on: schedule überhaupt auswertet, ist davon unberührt - und weiter offen (Stand 2026-08-31; seit 2026-09-01 geklärt, siehe unten)² .

.gitea/workflows/nightly.yml (seit 2026-08-31) implementiert diesen Drift-Check: on: schedule (17 3 * * * UTC) plus workflow_dispatch, kein Push-Trigger, dieselbe Runner-Form wie ci.yml. Diese Gitea-Instanz läuft 1.26.1 - weit über der 1.20-Version, die Actions-Schedules einführte, was den Trigger plausibel, aber nicht bewiesen macht³ . Zwei workflow_dispatch-Testläufe bestätigten zunächst nur, dass der Job selbst durchläuft (Run 85, alle sieben Schritte grün) - keiner davon ist ein schedule-Lauf. Offen bleibt weiterhin, ob der Cron-Trigger auf diesem Stand tatsächlich feuert - frühestens ab 2026-09-01 03:17 UTC zu beobachten, an einem Lauf mit "event":"schedule", nicht an einem weiteren workflow_dispatch-Erfolg (Stand 2026-08-31)³ .

Bestätigt seit 2026-09-01: Run 90 ist der erste Lauf der Repository-Historie mit "event":"schedule" - gestartet 2026-09-01T03:17:35Z, exakt zur konfigurierten Cron-Zeit, abgeschlossen 03:17:38Z, alle sieben Schritte grün. Dieser Gitea-1.26.1-Stand wertet on: schedule auf dem Default-Branch also tatsächlich aus; der im Issue vorgesehene externe Fallback (ein externer Cron gegen die Actions-API) war nicht nötig. Gitea-Issue #9 ist damit geschlossen.

Bekannte Probleme und Lösungen

Der Job-Container ist keine konfigurationsfreie Maschine (Beobachtet 2026-08-31)

Beobachtung: actions/checkout@v7 legt im Job-Container selbst eine globale git-Konfiguration an. Aus dem Log von Lauf 79 des Chemenu-CI (damals llm-wiki-test1): Copying '/root/.gitconfig' to '/tmp/<uuid>/.gitconfig' und Temporarily overriding HOME='/tmp/<uuid>' before making global git config changes. Ein git config --global --add safe.directory im eigenen Setup-Schritt schreibt zusätzlich hinein⁴ .

Warum das zählt: Ein CI-Container gilt gern als neutrale Umgebung - "hier ist nichts konfiguriert, also fällt auf, was von der Maschine gelesen wird". Für git stimmt das nicht mehr. Ein Test oder Guard, der sich darauf verlässt, hört still auf zu greifen: kein roter Lauf, keine Meldung, nur eine Prüfung, die nichts mehr prüft.

Konsequenz: Wer Umgebungsunabhängigkeit prüfen will, stellt sie explizit her (GIT_CONFIG_GLOBAL=/dev/null, eigenes HOME) statt sie vom Container zu erwarten. Siehe Ambient Environment Dependency.

doctor prüft eine Instanz, ein Checkout ist noch keine (Behoben 2026-08-31)

Problem: Der erste workflow_dispatch-Lauf von nightly.yml scheiterte am doctor-Schritt: FAIL git-identity: 'git config user.name' is not set und FAIL skills: No skills published yet³ .

Grundursache: doctor fragt, ob eine arbeitsfähige Instanz korrekt konfiguriert ist, nicht ob ein Checkout vollständig ist. .agents/skills/ und .claude/skills/ sind generiert und bewusst nicht committet (siehe instructions/bootstrap.md), existieren also erst nach wikitool instructions sync; und der Job-Container hat keine git-Konfiguration, unabhängig davon, ob WIKI_AUTHOR gesetzt ist - das deckt nur die separate author-Prüfung, nicht git-identity³ . Weil doctor den Job abbrach, wurde instructions verify nie erreicht - der Fehlschlag stand vor dem eigentlichen Prüfzweck des Laufs, nicht in ihm³ .

Lösung: Vor doctor eine echte git-Identität setzen (git config --global user.name/ user.email) und tools/wikitool instructions sync laufen lassen - ein Mechanismus deckt beide Prüfungen ab, statt zwei separate (git-Identität, WIKI_AUTHOR) je eine. Jeder Workflow, der doctor oder instructions verify auf einem frischen Checkout aufruft, braucht denselben Bootstrap³ .

JavaScript-Actions ohne node im Job-Image (Behoben 2026-08-30)

Problem: Jeder Lauf scheiterte an actions/checkout mit exec: "node": executable file not found in $PATH und exitcode '127'.

Grundursache: act_runner führt JavaScript-Actions mit node im Job-Container aus; das gepinnte debian:trixie-slim bringt keins mit. Das Runner-Label linux-docker war nie das Problem - es routete und startete den Container von Anfang an¹ .

Lösung: nodejs als erster Schritt vor dem Checkout installieren, Checkout auf actions/checkout@v7 heben. Ausführlich auf der Seite Act Runner.

Actions Cache Server-Konnektivität (Behoben 2026-07-12)

Problem: setup-go@v6 und andere Cache-verwendende Actions zeigten Timeout bei Versuch, den Cache-Server unter 172.18.0.2:39329 (interne Docker-Bridge-IP) zu erreichen.

Grundursache: Runner-Container befand sich in seinem eigenen Bridge-Netz (act_runner_default), während sich jeder Job-Container in einem isolierten temporären Bridge-Netz befand. Diese Netze konnten ohne Host-Routing nicht miteinander kommunizieren.

Lösung:

1. Änderte Runner-Container zu network_mode: host
2. Setzte cache.host auf statische IP 192.0.2.10
3. Cache-URL automatisch als ACTIONS_CACHE_URL injiziert
4. Vollständiger Neustart erforderlich: docker compose down && docker compose up -d

Beziehungen

• Teil von: Gitea-Ökosystem
• Ausgeführt von: Act Runner
• Nutzt: Docker für Container
• beobachtet über: Gitea MCP Server
• zeigte: Ambient Environment Dependency
• implementiert: CI Integration

Vorteile

• GitHub Actions kompatible Syntax
• Selbstgehostet, volle Kontrolle
• Integriert mit Gitea-Ökosystem
• Zero-Trust-ready mit 1Password-Integration
• Keine Vendor-Lock-in

Siehe auch

• Gitea - Git-Dienst
• Act Runner - Runner-Implementierung
• Host-VM
• Secrets-Verwaltung
• Build-System
• Docker - Container-Plattform concept
• Gitea MCP Server
• Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31
• Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31
• Ambient Environment Dependency
• CI Integration

Fußnoten

---

1. Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30 ↩︎

2. Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31 ↩︎

3. Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31 ↩︎

4. Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31 ↩︎