jinflow make

Der make-Befehl ist die Build-Pipeline. Er kompiliert YAML-Instrumente, fuehrt dbt aus und produziert den KLS.

Grundlegende Nutzung

jin make                                  # aktuellen Tenant bauen
jin make --tenant millesime.domaine_zufferey            # bestimmten Tenant bauen
jin make --pack alptrack                  # alle Tenants in einem Pack bauen
jin make --all                            # alle Tenants aller Packs bauen

Datensynchronisation (—sync)

--sync kopiert CSVs aus der Data Landing Zone (DLZ) in das raw/-Verzeichnis des Tenants vor dem Bau. Nur geaenderte Dateien werden kopiert (SHA-256-Vergleich gegen das vorherige Manifest).

jin make --sync                           # DLZ → raw → build synchronisieren
jin make --all --sync                     # alle Tenants, nur geaenderte CSVs kopieren
jin make --tenant millesime.domaine_zufferey --sync     # einzelner Tenant mit Sync

Extraktion (—extract)

--extract fuehrt quellsystem-spezifische Extraktionsskripte (z.B. Excel → CSV) im DLZ aus, bevor synchronisiert wird. Impliziert --sync.

jin make --extract                        # Excel → CSV → Sync → Build extrahieren
jin make --all --extract                  # alle Tenants extrahieren + synchronisieren + bauen

Nicht alle Quellsysteme haben Extraktionspipelines. Tenants ohne solche ueberspringen die Extraktion und fahren mit Sync fort.

Clean (—clean)

--clean loescht intermediäre Build-Artefakte (kompiliertes SQL, angereicherte CSVs) und erzwingt einen vollstaendigen Rebuild. Beruehrt nicht das AFS oder Rohdaten.

jin make --clean                          # sauberer Rebuild
jin make --tenant millesime.domaine_zufferey --clean    # einzelnen Tenant zuruecksetzen

Snapshots (—snapshot)

--snapshot friert den KLS nach einem erfolgreichen Build ein. Der Snapshot ist unveraenderlich — make verweigert das Ueberschreiben.

jin make --snapshot                       # auto-getaggt: YYYYMMDD-HHMM
jin make --snapshot post-audit            # benannter Snapshot

Flags

Flag	Wirkung
--sync	Geaenderte CSVs von DLZ → raw/ kopieren
--prune	Dateien aus raw/ entfernen, die nicht mehr im DLZ existieren (mit —sync)
--extract	Extraktionsskripte ausfuehren, bedingt durch Excel-Dateiaenderungen (impliziert —sync)
--clean	Sauberer Rebuild, Intermediäre loeschen
--snapshot [tag]	KLS nach Build einfrieren
--all	Alle Tenants aller Packs bauen
--pack <name>	Alle Tenants in einem Pack bauen
--tenant <id>	Bestimmten Tenant bauen (pack.tenant)
--continue-on-error	Nicht bei Compiler/dbt-Fehlern stoppen
--quiet	dbt-Ausgabe unterdruecken
--skip-enrich	CSV-Anreicherungsphase ueberspringen
--skip-validate	CSV-Schemavalidierung ueberspringen
--metadata-only	Nur Metadaten neu backen (Logo, Branding, About) — alle Build-Phasen ueberspringen

Build-Phasen

0a  Extrahieren       (--extract, quellsystem-spezifisch)
0b  Aus DLZ sync      (--sync, kopiert geaenderte CSVs nach raw/)
1a  CSVs validieren   (Schema-Check gegen Quellsystem-Definition)
1b  CSVs anreichern   (Taxonomie-Generierung, Backfill, Normalisierung)
2   Kompilieren       (YAML → dbt SQL: Signals, Theses, Verdicts, ...)
3   dbt Build         (Bronze → Silver → Gold → Signals → Theses → ...)
4   Nachbearbeitung   (Pipeline-Graph, Audit-Berichte, PDF-Generierung)
5   Stempeln + Paket  (Metadaten, AFS-Archiv, Snapshot)

Bedingtes Verhalten

• —extract hasht Excel-Dateien gegen _extract_manifest.json — ueberspringt Extraktion wenn unveraendert
• —sync kopiert nur CSVs, deren SHA-256-Hash sich vom vorherigen Sync-Manifest unterscheidet
• —prune entfernt Dateien aus raw/, die nicht mehr im DLZ existieren (Standard: nur Warnung)
• Systeme ohne Extraktion werden mit Info-Meldung uebersprungen (kein xslx/-Verzeichnis → keine Extraktionspipeline)
• Nur-Metadaten-Aenderungen automatisch erkannt: wenn sich nur tenant.yml, about.yaml, Logo oder jinflow.yml seit dem letzten Build geaendert haben, werden nur Metadaten neu gebacken ohne dbt auszufuehren. Auch verfuegbar als --metadata-only
• Inkrementelle Builds verwenden den bestehenden KLS wieder — dbt ueberspringt unveraenderte Modelle
• Fehlgeschlagene Builds werden beim Retry erkannt (fehlender KLS-Stempel → automatischer Neustart)

Beispiele

# Taegliche Routine: neue Daten synchronisieren, neu bauen
jin make --all --sync

# Nach Bearbeitung von Signals/Theses: ohne Neusynchronisation bauen
jin make

# Neuanfang nach Schema-Aenderungen
jin make --clean

# Nur Logo/Branding aktualisieren (kein Rebuild)
jin make --metadata-only

# Guten Zustand vor Aenderungen einfrieren
jin make --snapshot before-refactor

# Nur das Millesime-Pack bauen
jin make --pack millesime --sync

# Neue Excel-Dateien extrahieren, synchronisieren, bauen
jin make --tenant millesime.domaine_zufferey --extract