GitHub hat am 15. April 2025 mehrere bevorstehende Änderungen und Releases für GitHub Actions gebündelt angekündigt. Betroffen sind automatisch ausgelöste Workflows, das Windows-2019-Runner-Image, der Actions Runner Controller und Netzwerkfreigaben für Azure Private Networking. Für Unternehmen ist das kein einzelnes Update, sondern vier unterschiedliche Arbeitspakete mit eigenen Verantwortlichen und Risiken. Dieser Beitrag ordnet den bestätigten Stand ein und zeigt, wie sich die Änderungen kontrolliert vorbereiten lassen.
Was GitHub konkret angekündigt hat
Erstens sollen von GitHub Copilot erzeugte Ereignisse Actions-Workflows nicht mehr automatisch starten. In der damals angekündigten Public Preview müssen Administratoren solche Läufe freigeben. Ein betroffener Lauf erhält vor dem Start von Jobs den Status action_required. Nutzer mit Schreibzugriff in der Oberfläche oder der fein abgestuften API-Berechtigung actions:write können ihn genehmigen. Erfolgt innerhalb von 30 Tagen keine Freigabe, wird der Lauf gelöscht.
Zweitens begann GitHub mit der Stilllegung des gehosteten Windows-Server-2019-Runner-Images. Als vollständiges Enddatum nannte GitHub den 30. Juni 2025 und empfahl den Wechsel auf windows-2022 oder windows-2025. Für Juni 2025 waren außerdem zeitweise absichtlich fehlschlagende Jobs, sogenannte Brownouts, am 3., 10., 17. und 24. Juni jeweils zwischen 13:00 und 21:00 UTC angekündigt.
Drittens brachte Actions Runner Controller 0.11.0 laut GitHub zwei größere Erweiterungen: benutzerdefinierte Annotationen und Ressourcen für Bereitstellungswege wie ArgoCD und Helm sowie konfigurierbare Metriken. Hintergrund der Metrikänderung waren Leistungsprobleme durch Merkmale mit hoher Kardinalität, unter anderem Runner-Namen, IDs und Workflow-Referenzen, die den Ressourcenverbrauch von Prometheus-Instanzen erhöhen konnten.
Viertens korrigierte GitHub die Angaben zur Netzwerk-Allowlist für Azure Private Networking im Zusammenhang mit unveränderlichen Actions. Unternehmen sollten die IP-Adressen aus der NSG-Vorlage der GitHub-Dokumentation verwenden, weil frühere Changelog-Angaben überlappende CIDR-Bereiche enthielten.
Priorisierung: Deadline vor Optimierung
Aus GNS-Sicht sollte die Windows-2019-Migration zuerst behandelt werden, weil GitHub einen festen Abschalttermin und Brownouts genannt hat. Direkt danach folgt die Freigabelogik für Copilot-Ereignisse: Sie verursacht nicht zwingend technische Fehler, kann aber Automationen unbemerkt anhalten, wenn niemand action_required-Läufe beobachtet und freigibt. ARC 0.11.0 und die Azure-Allowlist sind stärker von der vorhandenen Architektur abhängig. Beide verdienen dennoch einen eigenen Verantwortlichen, weil Fehlkonfigurationen entweder Monitoring-Kosten oder Netzwerkverbindungen beeinträchtigen können.
- Inventur: Alle Workflows, Runner-Labels, ARC-Installationen, Copilot-bezogenen Trigger und Azure-Private-Networking-Abhängigkeiten erfassen.
- Kritikalität: Jeden Fund nach Ausfallwirkung, Frist, Datenzugriff und manueller Ersatzmöglichkeit bewerten.
- Test: Änderungen zuerst in einem begrenzten Repository oder einer nicht produktiven Runner-Gruppe mit realistischen Jobs prüfen.
- Freigabe: Technische Abnahme, Prozessverantwortung und Rückfallweg dokumentieren, bevor Labels, Controller oder Netzwerkregeln produktiv geändert werden.
- Nachkontrolle: Warteschlangen, action_required-Läufe, Jobfehler, Runner-Auslastung, Prometheus-Verbrauch und Netzwerkfehler getrennt beobachten.
Migrationsspur 1: Windows-2019-Runner ersetzen
Die reine Ersetzung des Labels durch windows-2022 oder windows-2025 ist nur der Anfang. Betriebssystemwechsel können vorinstallierte Werkzeuge, Pfade, Laufzeitversionen und Installationsskripte beeinflussen. Unternehmen sollten deshalb zunächst nach windows-2019 in Workflow-Dateien und wiederverwendbaren Vorlagen suchen, danach repräsentative Builds und Tests auf dem Ziel-Image ausführen und Abweichungen dokumentieren. Erst nach bestandener Prüfung wird das Label umgestellt. Ein Rückfall auf Windows 2019 war angesichts des angekündigten Enddatums keine dauerhafte Strategie.
- Direkte und indirekte Verwendungen des Labels windows-2019 finden.
- Abhängigkeiten von vorinstallierter Software und betriebssystemspezifischen Pfaden prüfen.
- Build, Test, Signierung und Deployment auf dem neuen Image separat validieren.
- Verantwortliche Teams und betroffene Fachprozesse vor der Umstellung informieren.
- Fehler während der angekündigten Brownout-Zeiten nicht als zufällige Instabilität behandeln.
Migrationsspur 2: Copilot-Läufe operativ freigeben
Die neue Freigabestufe ist eine Sicherheitskontrolle, verändert aber den Betriebsprozess. Wer Copilot-gestützte Pull Requests nutzt, muss festlegen, wer action_required-Läufe sieht, nach welchen Kriterien sie genehmigt werden und wie lange ein kritischer Lauf warten darf. Schreibzugriff oder actions:write sollte nicht pauschal erweitert werden, nur um Wartezeiten zu vermeiden. Sinnvoller ist eine klar benannte Gruppe mit dokumentierter Prüfung und Vertretung.
Für die Einführung empfiehlt sich ein Test mit einem unkritischen Repository: Copilot-Ereignis erzeugen, Sichtbarkeit im Merge-Bereich prüfen, Freigabe über Oberfläche und gegebenenfalls API nachvollziehen und die nachgelagerten Jobs kontrollieren. Zusätzlich braucht das Team einen Hinweis- oder Eskalationsweg für liegen gebliebene Läufe. Dass GitHub nicht freigegebene Runs nach 30 Tagen löscht, macht eine verlässliche Überwachung wichtiger als eine rein technische Dokumentation.
Migrationsspur 3 und 4: ARC und Azure getrennt behandeln
Bei ARC 0.11.0 sollte das Team zunächst klären, ob benutzerdefinierte Annotationen, Ressourcen oder konfigurierbare Metriken überhaupt benötigt werden. Wer ArgoCD oder Helm einsetzt, kann die neuen Möglichkeiten in einer separaten Runner-Gruppe testen. Bei Prometheus ist nicht die maximale Zahl an Labels das Ziel, sondern eine Reporting-Strategie mit den tatsächlich benötigten Dimensionen. Weniger Kardinalität kann den Betrieb vereinfachen; die konkrete Wirkung muss jedoch in der eigenen Umgebung gemessen werden.
Die Azure-Allowlist ist ein eigenes Netzwerk-Change. Verantwortliche sollten frühere, manuell übernommene CIDR-Bereiche identifizieren, die Werte mit der von GitHub benannten NSG-Vorlage abgleichen und die Änderung durch den regulären Netzwerkfreigabeprozess führen. Vor und nach der Anpassung sind Verbindungs- und Workflowtests nötig. Die alte Regel sollte erst entfernt werden, wenn der neue Pfad verifiziert und ein Rückfallplan dokumentiert ist.
Fazit: Vier Änderungen, vier Besitzer
Die GitHub-Ankündigung vom 15. April 2025 verbindet eine harte Runner-Frist mit neuen Workflow-Freigaben, einem ARC-Release und korrigierten Netzwerkinformationen. Unternehmen sollten daraus kein Sammelprojekt ohne Priorität machen. Der belastbare Weg beginnt mit der Windows-Inventur, definiert anschließend die Verantwortung für action_required-Läufe und behandelt ARC sowie Azure als getrennte Architekturänderungen. Wer jede Spur mit Test, Freigabe, Monitoring und Rückfallweg abschließt, reduziert Ausfallrisiken und macht die Migration für Fachbereiche und Betrieb nachvollziehbar.