torben/chemenu
1
1
Fork 0
Code Issues 26 Pull Requests Actions Packages Releases 32 Activity
Files
29063f511b02cedaf723b945de8504cb3e11d872
chemenu/kb/concepts/CI Integration.md
T
torben 18ae28f918
CI / verify (push) Failing after 32s
Details
Release / release (push) Successful in 38s
Details
Chemenu 2.1.0 - deterministischer Wissenskompiler 
Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki:
raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht
tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren
Grenzen in Code durchgesetzt sind statt im Prompt.

Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige
Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses
Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44
Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist.

Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den
Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er
dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs.

Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte.
Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet -
siehe NOTICE.
2026-09-01 16:26:14 +02:00

5.6 KiB
Raw Blame History

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
wikitool
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-Ereignis1 . 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 Korpus1 . 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)1 . 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 Issue1 .
  • 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

Beziehungen

Siehe auch

Fußnoten

Reference in New Issue View Git Blame Copy Permalink