chemenu/kb/concepts/CI Integration.md

---
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]]

<!-- wikitool:links -->
## Beziehungen

- **invokes:** [[wikitool]]
- **operates-on:** [[Gitea Actions]]
<!-- /wikitool:links -->