Dasselbe GitHub-Actions-Label kann jetzt auf AWS laufen
Ein Actions-Job kann heute bei einer externen Anmeldung scheitern, obwohl sein YAML unverändert ist. GitHub kündigte am 28. Oktober an, Linux-Rechenkapazität neben Azure auch über AWS bereitzustellen. Gleiches Label bedeutet damit nicht zwingend gleiche Ausgangsadresse.
Mehr Kapazität hinter bekannten Labels
Betroffen sind standardmäßige Linux-Runner mit 2 oder 4 Kernen sowie kompatible größere Runner dieser Größen ohne Sonderkonfiguration. Windows und private Netzwerke sind ausgenommen. Free, Pro und Team werden automatisch einbezogen; Enterprise Cloud kann AWS unter Actions > Hosted compute cloud providers aktivieren.
GitHub verteilt geeignete Jobs bei unveränderten Labels und unveränderter Syntax auf verfügbare Anbieter. Ziel sind kürzere kapazitätsbedingte Warteschlangen und höhere Ausfallsicherheit. Daraus folgt weder eine garantierte Beschleunigung des eigenen Jobs noch dessen doppelte Ausführung.
Warum Fehler sporadisch wirken können
Ein fiktiver Deployment-Dienst akzeptiert nur Azure-Adressen. Derselbe Workflow könnte aus Azure erfolgreich sein und aus dem erweiterten Pool abgewiesen werden. Auch Netzwerkbedingungen in Microsoft Entra Conditional Access können laut GitHub betroffen sein. Das ist ein Beispiel, kein selbst beobachteter Vorfall.
Vor einem Tokenwechsel lohnt der Vergleich von Zeitpunkt, Ziel, Quell-IP und Zielrichtlinie. Warten auf einen Runner und eine abgelehnte Anmeldung nach Jobstart sind unterschiedliche Phasen. Mehr Rechenkapazität behebt keine falsche Zugriffsregel.
IP-Adressen als Bereiche lesen
Ausgangspunkt ist das actions-Array von GET https://api.github.com/meta. Laut REST-Dokumentation sind aktuelle Werte abzufragen, statt Beispielwerte zu kopieren. Unser lokal ausgeführtes Python-ipaddress-Beispiel prüft den Dokumentationsbereich 192.0.2.0/24: .10 und .200 gehören dazu, 198.51.100.10 nicht. Das sind keine echten Runner-Adressen.
Alle Bereiche pauschal freizugeben passt nicht überall. Die Runner-Referenz rät wegen der vielen Standardbereiche von solchen Freigaben für interne Ressourcen ab und nennt größere Runner mit statischen IPs oder eigene Runner. Authentifizierung und minimale Rechte bleiben erforderlich.
Das Label bleibt, die Annahme ändert sich
Zuerst klären, ob der Fehler vor oder nach dem Jobstart entsteht. Anschließend aktuelle Bereiche und tatsächlich angewendete Richtlinien vergleichen. Wer einen festen Ausgang braucht, sollte einen dafür geeigneten Runner wählen. Ein Label ist kein verlässlicher Ersatz für die Identität des Cloud-Anbieters.