--- type: types/concept.md concept_type: workflow tags: [pre-commit, hooks, automation, quality-control] created: 2026-08-03 modified: 2026-09-01 related: - invokes: wikitool - operates-on: Gitea Actions sources: [Source - LLM Improvements Codex Analysis, Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31] confidence: 0.80 confidence_base: 0.80 provenance: sourced summary: '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[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31]. 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[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31]. ~~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)[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-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[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31]. - Ein Pre-Commit-Hook (lokale Prüfung vor `git commit`) ist bisher **nicht** eingerichtet - beide bestehenden Workflows sind serverseitig. - **`ci.yml`s 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, `doctor`s 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]][^s-llm-improvements-codex-analysis] ## Beziehungen ## Siehe auch - [[Source - LLM Improvements Codex Analysis]] ## Fußnoten [^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31]: [[Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]] [^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]] ## Beziehungen - **invokes:** [[wikitool]] - **operates-on:** [[Gitea Actions]]