GitHub Actions: Release-Belege über den grünen Haken hinaus
Am Release-Tag wirken ein grüner Haken und ein CI-Link ausreichend. Monate später kann der Link fehlen. Eine bestandene Prüfung zu erinnern ist nicht dasselbe, wie ihren Umfang belegen zu können.
GitHub meldete am 1. Oktober 2026 die Erweiterung der Actions-Aufbewahrung auf Prüfungen, Workflow-Läufe und Statusmeldungen. Die folgenden Schritte sind ein technischer Vorschlag, keine zusätzlichen GitHub-Vorgaben.
Den Geltungsbereich prüfen
Auch Prüfungen und Statusmeldungen von Drittanbieter-Apps werden nach Ablauf automatisch bereinigt. Organisations- und Enterprise-Grenzen gelten weiter; öffentliche Repositories haben höchstens 90 Tage. Entfernte Daten werden durch neue Einstellungen nicht wiederhergestellt.
Suchen Sie Releases, deren einziger Beleg ein Workflow-Link ist. Prüfergebnisse, Freigaben und Artefakt-Hashes können verteilt liegen. Bleibt die Verbindung nachvollziehbar, wenn ein Link ausfällt?
Ein Belegpaket pro Release
Erfassen Sie commit SHA, Release-Namen, Lauf-ID und URL, Ergebniszeit, Testzusammenfassung und Artefakt-Hash. Dokumentieren Sie Freigaben, aber kopieren Sie keine Rohlogs mit Geheimnissen. Zweck und Leserechte gehören dazu.
Ein bestanden erklärt nicht den Testumfang. Beschreiben Sie Teilprüfungen, Runtime und relevante Lockdateien. Verweisen Sie auf Dateien am Release-Commit, damit spätere Änderungen nicht als damalige Konfiguration erscheinen.
Export vor Automatisierung testen
Wählen Sie ein Repository und ein Release. Prüfen Sie Einstellung und Organisationsgrenze, speichern Sie eine Zusammenfassung und lassen Sie jemand anderen das Release ohne CI-Link erklären.
Der Export schafft eine weitere Sicherheitsgrenze. Legen Sie Eigentümer, Frist, Schreibrechte und Bereinigung von Geheimnissen fest. Dauerhafte Release-Belege und kurzfristige Debugging-Daten brauchen unterschiedliche Zwecke.
Fehlende Historie nicht als Fehler deuten
Prüfen Sie Aufbewahrung, Rechte und Abfragefilter, bevor ein leeres API-Ergebnis als nie ausgeführter Test gilt. Vergleichen Sie Lauf-ID und unabhängige Belege. Das ist eine praktische Prüffrage, keine behauptete Community-Mehrheit.
Ergänzen Sie diese Woche Belegort und Ablaufdatum im Release-Template und lesen Sie ein Paket zurück. Längere CI-Aufbewahrung allein erfüllt nicht automatisch alle Audit-Anforderungen. Entscheidend ist eine nachvollziehbare Erklärung mit klaren Grenzen.