chemenu/kb/concepts/CI Integration.md

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

type	concept_type	tags	created	modified	related	sources	confidence	confidence_base	provenance	summary
types/concept.md	workflow	pre-commit hooks automation quality-control	2026-08-03	2026-09-01	invokes wikitool operates-on Gitea Actions	Source - LLM Improvements Codex Analysis Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31	0.80	0.80	sourced	CI/CD-Hooks vor dem Publish: ci.yml (Push/PR, Stack-Pfade, seit 1.8.1 mit Coverage-Messung ohne Schwelle) und nightly.yml (Zeitplan, schliesst die paths-ignore-Luecke fuer Content-Drift; schedule-Ausloesung seit 2026-09-01 bestaetigt) setzen Quality Gates durch

CI Integration

Typ: workflow

Definition

CI Integration bezieht sich auf die Einrichtung von Pre-Commit-Hooks und CI/CD-Pipelines, die automatisch Quality Gates durchsetzen, bevor Änderungen im Repository veröffentlicht werden. Dies stellt sicher, dass Regressionen früh abgefangen werden und das Wiki jederzeit strukturelle Integrität bewahrt.

Kernpunkte

• Umgesetzt, nicht mehr nur geplant: .gitea/workflows/ci.yml läuft seit 1.2.0 bei jedem Push/PR auf Stack-Pfaden und führt docs verify, instructions verify und lint --fail-on-error aus, bevor dist export die Verteilung prüft.
• paths-ignore schließt Content-Commits explizit aus (kb/, raw/, work/, reports/) - ein reiner Wiki-Publish löst also keinen CI-Lauf aus. Das ist gewollt (publish fasst bei jedem Ingest kb/ an, die volle Suite dafür zu fahren wäre Lärm), öffnet aber eine Lücke: strukturelle Regression im Korpus selbst fällt zwischen zwei Content-Publishes niemandem auf. Siehe Gitea Actions für den Beleg, dass der Filter tatsächlich greift.
• Diese Lücke schließt ein zweiter, geplanter Workflow, nicht ein Pre-Commit-Hook: .gitea/workflows/nightly.yml (seit 2026-08-31, Gitea-Issue #9) läuft on: schedule plus workflow_dispatch und fährt doctor, docs verify/instructions verify, lint --fail-on-error, sources coverage und migrate status unabhängig vom Push-Ereignis¹ . Ein Workflow, der doctor auf einem frischen Checkout aufruft, braucht denselben Bootstrap wie ein neuer Clone (git-Identität, instructions sync) - sonst scheitert er an der eigenen Startbedingung, nicht am Korpus¹ . Ob der schedule-Trigger auf dieser Gitea-Instanz tatsächlich feuert, ist noch unbeobachtet - bislang bewiesen nur, dass der Job selbst läuft (Stand 2026-08-31)¹ . Beobachtet seit 2026-09-01: Run 90 feuerte als erster Lauf mit "event":"schedule", exakt zur konfigurierten Cron-Zeit (17 3 * * * UTC), alle sieben Schritte grün - der Trigger funktioniert also auf diesem Gitea-1.26.1-Stand tatsächlich, Gitea-Issue #9 ist geschlossen.
• Fehlersichtbarkeit ist eine bewusste Nutzerentscheidung, kein Automatismus: ein fehlgeschlagener nightly-Lauf meldet sich über Giteas eigene Run-Notification, nicht über ein automatisch angelegtes Issue¹ .
• Ein Pre-Commit-Hook (lokale Prüfung vor git commit) ist bisher nicht eingerichtet - beide bestehenden Workflows sind serverseitig.
• ci.ymls Tests-Schritt misst seit 1.8.1 Coverage und weist sie als Artefakt aus, ohne Abbruchschwelle - siehe Messen vor Schwelle für die Begründung der Reihenfolge. Konfiguration in tools/.coveragerc, nicht pytest.ini, weil coverage.py Letzteres nicht liest.

Beispiele

• ci.yml: docs verify + instructions verify + lint --fail-on-error bei jedem Stack-Push/PR, danach dist export und ein Replay von setup-instance.md gegen die Export.
• nightly.yml: dieselben Kernprüfungen auf einem Zeitplan statt auf einen Push, damit Korpus-Drift zwischen zwei Content-Publishes nicht unbemerkt bleibt.

Implementierungshinweise

Beide Workflows teilen sich dieselbe Runner-Form (Debian trixie-slim, nodejs vor dem Checkout, actions/checkout@v7) - siehe Gitea Actions für die Begründung und die dort dokumentierten Fallstricke (fehlendes node im Image, git-Konfiguration im Job-Container, doctors Bootstrap-Anspruch an eine Instanz statt an einen bloßen Checkout).

Wann zu verwenden

• In jeder produktiven oder gemeinsam genutzten Wiki-Bereitstellung
• Um Konsistenz über mehrere Mitwirkende durchzusetzen
• Um Fehler vor Erreichen des Hauptzweigs abzufangen

Wann NICHT zu verwenden

• In früher Entwicklung, wenn sich Regeln häufig ändern
• Für Single-Contributor-Test-Repos, bei denen manuelle Prüfungen ausreichend sind

Verwandte Concepts

• Lint Workflow (Lint ist eine Schlüssel-CI-Prüfung)
• Source - LLM Improvements Codex Analysis²

Beziehungen

Siehe auch

• Source - LLM Improvements Codex Analysis

Fußnoten

Beziehungen

• invokes: wikitool
• operates-on: Gitea Actions

---

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

2. Source - LLM Improvements Codex Analysis ↩︎