Mika/ci_policy_evaluation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ci_policy_evaluation/policy_definition/README.md

4.7 KiB
Raw Blame History

CI-Policy v0.1 – Definition und Evaluierung für PASS/WARN/FAIL Entscheidungen

Purpose

Formale Definition einer Continuous-Integration-Policy, die Gate-Entscheidungen aus Debug-Daten automatisiert und nachvollziehbar trifft.

Problemstellung: Bisherige Entscheidungslogik in CI-Gates war inkonsistent und interpretierbar. Ziel ist eine deterministische, testbare Policy, die WARN- und FAIL-Bereiche formal abgrenzt.

Ziele:

  • Reduktion subjektiver Entscheidungen in CI-Ergebnissen
  • Standardisierung der Kategorien PASS, WARN und FAIL
  • Einführung maschinenlesbarer Regeldefinition für Gate-Entscheidungen

Kontext & Hintergrund

Backtest-CSV-Daten (#20–#29) mit Debug-JSON-Ausgaben je Run

Gruppierung:

  • pinned
  • unpinned

Trace-Metadaten / zusätzliche Tags:

  • margin
  • decision
  • flaky_flag
  • subset_flipcount
  • mischfenster_p95

Domänenkontext:

  • Continuous Integration
  • Automatisiertes Testen
  • Qualitätssicherung von CI-Gates

Motivation:

  • Formalisierung bisher intuitiver Gate-Entscheidungen
  • Stabilisierung der Bewertung von knappen Testergebnissen (Margin-Zone)
  • Reduzierung von Flip-Flops zwischen Runs durch konsistente Regeln

Methode / Spezifikation

Übersicht:

  • Die Policy nutzt Metriken aus Debug-JSON zur Festlegung deterministischer Entscheidungen in CI-Läufen.
  • Regeln sind in YAML definiert, maschinenlesbar und unit-testbar.

Algorithmen / Verfahren:

  • PASS → allow
  • WARN → allow + label + Auto-Rerun
  • FAIL → block
  • WARN wird getriggert, wenn Margin-Zone oder flaky_flag zutrifft

Bootstrap-Übersicht

Nicht anwendbar – deterministische Regelbewertung, kein Resampling.

Zielgrößen:

Input / Output

Input-Anforderungen

Hardware: Software:

  • Python >=3.8
  • YAML Parser
  • CI-System (z. B. GitHub Actions, Jenkins)

Konfiguration:

  • Integration der YAML-Policy in CI-Pipeline als Validierungsstufe

Erwartete Rohdaten

Felder pro Run:

  • timestamp
  • run_id
  • decision
  • margin
  • flaky_flag
  • subset_flipcount
  • mischfenster_p95

Formatbeispiele:

  • 2024-02-10T08:33:20Z, run_020, WARN, 0.04, true, 1, 0.87

Trace-Daten:

  • Format: JSON
  • Hinweis: Debug-JSON pro Run liefert Basisdaten für Policy-Entscheidung

Analyse-Ausgaben

Pro Gruppe / pro Governor: Vergleichsausgaben:

  • Trace-Muster: Analyse von WARN-Raten im Zeitverlauf als Indikator für Policy-Drift

Workflow / Nutzung

Analyse-Workflow:

  • Debug-JSONs aus CI-Runs sammeln.
  • Policy auf Debug-JSON anwenden, Entscheidung ableiten.
  • Per Run eine Zeile als Report-Artefakt schreiben.
  • Mittlere WARN-Rate überwachen, Threshold-basierte Alarme setzen (z. B. >30% über 20 Runs).

Trace-Template-Anforderungen

Ziel: Einheitliche Auswertungskriterien für alle CI-Runs.

Erforderliche Tags & Metadaten:

  • margin
  • flaky_flag
  • decision

trace-cmd-Setup:

  • Policy automatisch im Post-Test-Step ausführen
  • Ergebnis als CSV-Zeile im Artefaktordner speichern

Run-Design für Contributors:

  • Jeder Commit löst einen CI-Run aus
  • Policy bewertet Run-Ergebnisse deterministisch
  • WARN-Runs werden automatisch rerunnt

Interpretation & erwartete Ergebnisse

Kernbefunde:

  • pinned-Runs bleiben stabil im PASS/WARN-Bereich
  • unpinned-Runs tragen Hauptanteil der WARN-Entscheidungen
  • keine Fehlklassifikation durch Margin-Anpassung
  • kritische Flip-Flops werden formal eliminiert

Implikationen für Experimente:

  • Policy-Design verbessert Konsistenz und Nachvollziehbarkeit von Gate-Entscheidungen
  • Automatische Reruns reduzieren unnötige FAIL-Blöcke
  • Drift-Monitoring erlaubt langfristige Quantifizierung der Policy-Stabilität

Planungsziel:

  • Ziel: Evaluiere Stabilität und Drift der Policy durch fortlaufende CI-Metrikerfassung.
  • Vorgehen:
    • Messung der WARN-Rate über sequenzielle Runs
    • Schwellwert-Alarmierung bei Policy-Drift

Limitationen & Fallstricke

Datenbezogene Limitationen:

  • Backtest-Datensatz ist statisch; neue Laufdaten können abweichende WARN-Verteilungen zeigen

Kausalität & Generalisierbarkeit:

  • Policy-Validität hängt von Stabilität der zugrundeliegenden Metriken ab

Praktische Fallstricke:

  • Zu enge Margins können unnötige WARNs erzeugen
  • Fehlerhafte flaky_flag-Erkennung beeinflusst Ergebnisqualität

Nächste Schritte & Erweiterungen

Geplante Experimente:

  • Implementierung eines Policy-Drift-Monitors zur Überwachung von WARN-Raten

Analyseziele:

  • Langzeitstatistik von PASS/WARN/FAIL
  • Analyse saisonaler Schwankungen in flaky_flag-Raten

Regression & Modellierung:

  • Evaluierung einer adaptiven Margin-Zone basierend auf historischen Stable-Runs

Community-Beiträge:

  • Open-Source-Veröffentlichung der YAML-Policy und CI-Runner-Integration
  • Feedback-Sammlung zu WARN-Interpretation (soft fail vs. block with rerun)