Build abgeschlossen, aber Protokolle, Zusammenfassungen oder Artefakte fehlen.
Schnellste Prüfung: Bei einer passenden Wildcard-Regel ist meist keine Einzeländerung nötig; bei einzeln aufgeführten Hosts gleichen Sie die aktuelle offizielle Liste ab und testen einen echten Workflow.
Für wen ist dieser Ablauf gedacht? Für Administratoren, die Unternehmens-Firewalls, Proxyregeln oder DNS-Filter verwalten und die Abdeckung neuer Blob-Storage-Hosts prüfen müssen. Für Plattformingenieure mit selbst gehosteten Mac-Runnern, die CI-Protokolle, Zusammenfassungen und Artefakte zuverlässig übertragen müssen. Für IT- und Release-Verantwortliche, die eine überprüfbare Freigabe und einen wiederholbaren Prozess für spätere Änderungen brauchen.
Zuletzt geprüft am 27.10.2026; abgeglichen mit der GitHub-Ankündigung vom 22.10.2026, der Meta-API-Dokumentation und den Anforderungen an selbst gehostete Runner. GitHub bestätigte die Änderung für GitHub.com. Die Ankündigung nennt keinen einheitlichen verbindlichen Stichtag; sie belegt außerdem keine entsprechende Änderung für GitHub Enterprise Server. GitHub-Ankündigung zu den aktualisierten Actions-Blob-Storage-Endpunkten
1. Zuerst die Regelart Ihrer Mac-CI-Firewall bestimmen
Die entscheidende Frage lautet nicht, ob Ihr Workflow oder Ihr Runner-Label geändert wurde, sondern auf welcher Grundlage die Firewall den ausgehenden Zugriff erlaubt: anhand einzelner Hostnamen, eines passenden Wildcards oder anhand von IP-Adressen. Diese Regeltypen sind nicht austauschbar. Eine Hostnamenregel prüft einen Namen, eine IP-Regel eine aufgelöste Adresse; eine Änderung auf der einen Ebene erweitert die andere nicht automatisch.
Die GitHub-Ankündigung vom 22.10.2026 beschreibt neu hinzugefügte Hostgruppen für Actions Blob Storage und unterscheidet ausdrücklich zwischen Organisationen, die passende Wildcard-Regeln verwenden, und solchen, die Hosts einzeln freigeben. Wenn Sie Hosts einzeln eintragen, müssen Sie die aktuelle offizielle Angabe mit Ihrer Richtlinie abgleichen. Deckt eine bestehende Wildcard die betroffenen Hostnamen bereits ab, ist eine zusätzliche Einzelregel laut Ankündigung üblicherweise nicht erforderlich. Prüfen Sie trotzdem, ob Ihre Sicherheitsvorgaben und DNS- oder Proxyregeln diese Wildcard tatsächlich zulassen. Die offizielle Änderungsbeschreibung legt den Geltungsbereich und die betroffenen Freigabemuster fest.
| Vorhandene Regel | Was Sie prüfen | Vorläufige Entscheidung |
|---|---|---|
| Einzelne Hostnamen | Stimmen die Einträge mit den aktuell veröffentlichten Storage-Hosts überein? | Fehlende Einträge gezielt ergänzen und im Workflow testen. |
| Passendes Wildcard | Erfasst das Muster beide in der Ankündigung genannten Hostgruppen, und lässt die Richtlinie deren Auflösung zu? | In der Regel keine neue Einzelregel; Abdeckung und Verhalten dennoch verifizieren. |
| IP-Adressen | Enthält die Regel die relevanten aktuellen Actions-IP-Bereiche, und ist die Regel für den tatsächlichen Datenpfad geeignet? | Mit Meta-API-Daten und Firewallprotokollen prüfen; eine IP-Liste nicht als Hostnamenliste behandeln. |
| Breite allgemeine Freigabe | Ist sie für die betroffene Netzwerkzone ausdrücklich genehmigt? | Nicht allein für diese Änderung pauschal öffnen; auf eng begrenzte Regeln zurückgehen. |
Die Änderung betrifft weder Runner-Labels noch Workflow-Dateien. Sie ist auch kein allgemeiner Hinweis, sämtliche GitHub-Endpunkte neu freizugeben. Halten Sie deshalb den Regelumfang auf den Actions-Blob-Storage-Datenpfad beschränkt und dokumentieren Sie getrennt, ob Ihre Firewall Namen, IP-Bereiche oder beides bewertet.
2. Hostnamenabdeckung und IP-Abdeckung getrennt bewerten
Die richtige Regel hängt von der tatsächlich verwendeten Durchsetzungsebene ab. Ein Proxy kann Hostnamen filtern, während eine Netzwerk-Firewall nach IP-Adressen entscheidet. Manche Unternehmen nutzen beide Kontrollen: Dann reicht es nicht, nur die sichtbare Proxyregel zu prüfen. Der Mac-Runner kann den richtigen Hostnamen anfragen und trotzdem an einer IP-basierten Egress-Regel scheitern.
Die offizielle Ankündigung nennt zwei Hostgruppen. Übernehmen Sie deren Schreibweise aus der Ankündigung, statt sie aus alten Tickets, kopierten Firewallobjekten oder einem früheren Screenshot zu rekonstruieren. Die GitHub Meta API stellt aktuelle Metadaten bereit; der aktuelle Endpunkt ist api.github.com/meta. Für IP-basierte Richtlinien ist insbesondere der Actions-Bereich der Antwort relevant. Ersetzen Sie damit jedoch nicht stillschweigend eine Hostnamenregel: Ein IP-Bereich beantwortet nicht automatisch die Frage, ob eine Wildcard den benötigten DNS-Namen umfasst.
| Prüfpunkt | Hostnamenbasierte Kontrolle | IP-basierte Kontrolle |
|---|---|---|
| Primäre Quelle | Aktuelle Hostangaben in der offiziellen Ankündigung und in den Netzwerkunterlagen | Aktuelle Actions-IP-Bereiche aus der Meta API |
| Typischer Fehler | Ein neuer Host fehlt in der Liste oder ein Wildcard-Muster passt nicht | Bereich veraltet, falsche Regelzone oder Namensauflösung führt zu einer nicht erlaubten Adresse |
| Nachweis | Regeldefinition, DNS-/Proxyprotokoll und Workflow-Ergebnis | Meta-API-Abgleich, Firewalltreffer und Workflow-Ergebnis |
| Rückfall bei unklarer Abdeckung | Eng begrenzt testen und fehlende Hosts gezielt ergänzen | Regeländerung mit Netzwerkteam prüfen, statt pauschal den Egress zu öffnen |
curl -fsS https://api.github.com/meta | jq '.actions'Behandeln Sie die Ausgabe als aktuellen Datenpunkt, nicht als dauerhaft gültige Konfiguration. GitHub beschreibt die Meta API als Quelle für Metadaten und weist in der API-Dokumentation darauf hin, dass sich Inhalte ändern können. Vergleichen Sie daher den für Ihre Richtlinie relevanten Abschnitt mit dem zuletzt freigegebenen Stand und halten Sie Abrufdatum sowie die daraus abgeleitete Regeländerung fest. Wenn Sie nur Hostnamen filtern, dokumentieren Sie zusätzlich, welche offizielle Hostliste Ihrer Regel zugrunde liegt.
Wie bestätigen Sie, dass Ihre Whitelist die neuen Speicherziele abdeckt? Prüfen Sie die Regel selbst und korrelieren Sie sie mit einem tatsächlichen Verbindungsversuch. Eine Regel, die im Konfigurationssystem gut aussieht, ist kein ausreichender Nachweis, wenn ein Proxy davor, eine DNS-Filterung oder eine zweite Egress-Kontrolle den Zugriff weiterhin verhindert.
3. Entscheidung nach Regeltyp treffen, statt pauschal zu öffnen
Nutzen Sie die folgende Entscheidungsfolge, bevor Sie Änderungen in einer produktiven Mac-CI-Zone freigeben:
- Wenn Ihre Richtlinie einzelne Hostnamen aufführt, gleichen Sie jeden relevanten Eintrag mit den aktuellen offiziellen Actions-Blob-Storage-Angaben ab. Fehlen dort Ziele, ergänzen Sie nur die erforderlichen Einträge und starten anschließend einen repräsentativen Workflow.
- Wenn Ihre Richtlinie eine Wildcard verwendet, prüfen Sie, ob das Muster beide angekündigten Hostgruppen erfasst und ob Proxy, DNS-Filter und Firewall dieselbe Interpretation verwenden. Ist die Abdeckung belegt, ist normalerweise keine zusätzliche Hostregel nötig.
- Wenn Ihre Kontrolle IP-basiert ist, gleichen Sie die Actions-IP-Bereiche mit dem aktuellen Meta-API-Ergebnis ab. Verifizieren Sie zugleich, dass die betroffene Firewallregel für den Runner-Ausgang gilt und nicht nur für eine andere Zone.
- Wenn Sie die Regelart oder den tatsächlichen Datenpfad nicht sicher bestimmen können, ändern Sie die Produktionsfreigabe noch nicht. Lassen Sie zuerst eine Verbindung in der betroffenen Zone protokollieren und stimmen Sie den Befund mit dem Netzwerkverantwortlichen ab.
- Wenn nach einer gezielten Änderung weiter Fehler auftreten, erweitern Sie nicht automatisch die Freigabe. Nutzen Sie DNS-, Proxy- und Firewallprotokolle, um Ablehnung, Namensauflösung und Berechtigungsprobleme voneinander zu unterscheiden.
Für die Bewertung können Sie intern eine einfache Punkteskala verwenden: volle Wertung, wenn Regeltyp, Quelle, Trefferprotokoll und Workflow-Ergebnis zusammenpassen; teilweise Wertung, wenn die Konfiguration plausibel ist, aber ein Lauf oder ein Lognachweis fehlt; keine Freigabe, wenn nur eine Vermutung oder ein alter Eintrag vorliegt. Die Wertung ist ein internes Prüfwerkzeug, keine von GitHub vorgegebene Sicherheitsbewertung.
4. Quellenstand und Aktualisierung nachvollziehbar halten
GitHub Actions Meta API ist als Suchbegriff oft mit „die komplette Hostliste aus dem API-Aufruf übernehmen“ verbunden. Trennen Sie dabei drei Dinge: die API-Antwort, die im offiziellen Änderungsbeitrag genannten Storage-Hosts und die Regeln, die Ihr Unternehmen tatsächlich durchsetzt. Eine JSON-Antwort mit IP-Bereichen ist nicht automatisch eine vollständige Liste der Hostnamen, die eine Proxy-Whitelist benötigt. Umgekehrt beweist eine Hostnamenregel nicht, dass ein IP-basierter Egress-Pfad offen ist.
Als Mindestnachweis gehören in den Change-Datensatz: die verwendete GitHub-Quelle, der Zeitpunkt der Prüfung, die geprüfte Regelart, die betroffene Runner-Netzwerkzone, die Änderung oder die begründete Entscheidung gegen eine Änderung sowie das Ergebnis des Testlaufs. Speichern Sie nicht nur einen Screenshot. Ein maschinenlesbarer API-Auszug oder ein exportierter Regelstand ist leichter mit späteren Änderungen zu vergleichen, sofern Ihre Aufbewahrungs- und Datenschutzregeln das erlauben.
Die Dokumentation zu den Netzwerkkommunikationsanforderungen selbst gehosteter Runner ist die Referenz, um die Blob-Storage-Prüfung in die übrigen Verbindungen eines Runners einzuordnen. Sie ist nicht gleichbedeutend mit einer universellen Freigabeliste für jede Unternehmensumgebung. Prüfen Sie die jeweils für Ihre Runner-Konfiguration erforderlichen Ziele und übertragen Sie nicht ungeprüft die Anforderungen eines anderen Runner-Typs auf einen selbst gehosteten Mac.
Für die regelmäßige Pflege legen Sie einen Verantwortlichen fest und definieren klare Auslöser statt eines unbelegten, vermeintlich verbindlichen Intervalls. Sinnvolle Auslöser sind eine neue GitHub-Ankündigung zu Actions-Endpunkten, eine Änderung der Meta-API-Daten, eine Aktualisierung der Runner-Netzwerkdokumentation oder eine unternehmensinterne Änderung an Proxy, DNS-Filter oder Firewall. Prüfen Sie den relevanten Stand vor einer Freigabe und bei einem solchen Auslöser erneut. Die GitHub-Ankündigung vom 22.10.2026 setzt keinen allgemeinen Stichtag für die Anpassung; erfinden Sie daher keinen organisationsübergreifenden Zeitdruck.
5. Funktionen im Workflow gezielt abnehmen
Blob-Storage-Ziele sind nicht mit GitHub-API-Aufrufen, dem Abruf des Quellcodes oder einer Xcode-Installation gleichzusetzen. Werden Protokolle, Zusammenfassungen oder Artefakte nicht angezeigt, kann eine blockierte Storage-Verbindung eine Ursache sein; der Fehler beweist aber nicht, dass die neue Hoständerung verantwortlich ist. Prüfen Sie die Funktion, die tatsächlich ausgefallen ist, und ordnen Sie sie dem passenden Netzwerkpfad zu.
Die GitHub-Dokumentation zu Workflow-Artefakten beschreibt den Artefakttransport als eigenen Workflow-Bereich. Die Dokumentation zum Dependency Caching behandelt wiederum das Speichern und Wiederverwenden von Abhängigkeiten. Falls Ihr Team Caches nutzt, testen Sie deren tatsächlichen Schreib- und Leseweg separat; ein erfolgreicher Artefakt-Upload beweist nicht, dass auch ein Cache-Treffer oder Cache-Upload funktioniert. Variablen, mit denen Workflows Informationen steuern, sind ebenfalls ein anderer Prüfgegenstand als Netzwerkregeln; verwenden Sie dafür die GitHub-Referenz zu Workflow- und Actions-Variablen.
Ein belastbarer Mac-CI-Test umfasst einen normalen Lauf im betroffenen Netzwerk und kontrolliert die von Ihrem Team tatsächlich verwendeten Funktionen. Verifizieren Sie, dass die Workflow-Protokolle lesbar sind, eine Zusammenfassung im Lauf erscheint und der benötigte Artefakttransport funktioniert. Wenn der Build von Caches abhängt, prüfen Sie zusätzlich einen vorgesehenen Cache-Zugriff. Ein Test muss nicht alle Funktionen künstlich in einen Workflow pressen; er muss aber die kritischen Übertragungswege Ihrer Release-Pipeline abdecken.
Warum fehlen nach einem erfolgreichen Mac-Build Protokolle oder eine Workflow-Zusammenfassung? Ein erfolgreich abgeschlossener Build beweist nicht, dass alle nachgelagerten Übertragungen funktioniert haben. Prüfen Sie den tatsächlichen Netzwerkfehler, die Workflow-Berechtigungen und den relevanten Speicherpfad. DNS-Fehler, Proxyablehnungen und Firewall-Drops weisen auf unterschiedliche Ursachen hin; ein Berechtigungsfehler ist nicht durch eine zusätzliche Hostfreigabe zu beheben.
6. Mit echten Logs abnehmen und den Betrieb dokumentieren
Führen Sie die Prüfung in der Netzwerkzone durch, in der der selbst gehostete Mac-Runner tatsächlich arbeitet. Ein erfolgreicher Test auf einem Administrator-Laptop oder in einem anderen VLAN belegt nicht die Erreichbarkeit aus dem Runner-Netz. Notieren Sie Workflow-Lauf, Zeitpunkt, Runner-Zuordnung, Regeländerung und die betroffenen Protokolle, damit ein späterer Fehler mit demselben Pfad verglichen werden kann.
- Ausgangslage sichern. Exportieren Sie die vorhandene Regel oder dokumentieren Sie deren exakte Match-Bedingung. Erfassen Sie, ob sie Hostnamen, Wildcards, IP-Bereiche oder eine Kombination davon verwendet.
- Offizielle Daten abgleichen. Vergleichen Sie die Hostgruppen aus der GitHub-Ankündigung mit Hostregeln und prüfen Sie bei IP-basierter Durchsetzung den passenden Actions-Abschnitt der aktuellen Meta-API-Antwort.
- Änderungsumfang begrenzen. Ergänzen Sie bei Bedarf nur die fehlenden Ziele und halten Sie fest, welche Regel die Änderung aufnimmt. Wenn eine passende Wildcard schon gilt, dokumentieren Sie die Prüfung statt eine überflüssige Einzelregel anzulegen.
- Einen repräsentativen Mac-Workflow starten. Verwenden Sie einen Lauf aus der tatsächlichen Runner-Zone und prüfen Sie mindestens die für Ihr Team kritischen Log-, Zusammenfassungs- und Artefaktwege. Testen Sie Cache-Funktionen zusätzlich, wenn sie Bestandteil des Build-Ablaufs sind.
- Logs und Ergebnis korrelieren. Vergleichen Sie Workflow-Zeitpunkt und Runner-Protokolle mit DNS-, Proxy- und Firewallereignissen. Unterscheiden Sie ausdrücklich zwischen abgewiesener Verbindung, fehlgeschlagener Namensauflösung und fehlenden Berechtigungen.
- Abnahme oder Rückfall dokumentieren. Schließen Sie die Änderung erst, wenn der benötigte Workflow-Pfad erfolgreich ist und die Regel nachvollziehbar bleibt. Bei unklarer Ursache rollen Sie eine nicht belegte Erweiterung zurück oder halten sie außerhalb der Produktion, statt die Freigabe vorsorglich zu verbreitern.
| Beobachtung im Test | Wahrscheinliche Prüfebene | Nächster Schritt |
|---|---|---|
| DNS kann den benötigten Host nicht auflösen | DNS-Filter, Resolver oder Namensregel | Auflösung in der Runner-Zone prüfen und Regelzuständigkeit klären |
| Proxy oder Firewall protokolliert eine Ablehnung | Proxyregel, Hostliste oder IP-Egress | Ablehnungsziel mit der offiziellen Quelle und der Regelart vergleichen |
| Netzwerkzugriff gelingt, aber Artefakt oder Zusammenfassung fehlt | Workflow-Berechtigung oder Funktionskonfiguration zusätzlich prüfen | Artefakt- beziehungsweise Workflow-Protokoll untersuchen |
| Protokolle und benötigte Übertragungen funktionieren | Regel und Workflow sind für den geprüften Pfad abgenommen | Quelle, Regelstand und Testnachweis zur späteren Wiederholung ablegen |
Betrieb mit MACGPU als getrennte Netzwerkentscheidung betrachten
Wenn Sie einen bestehenden Mac im eigenen Rechenzentrum weiterbetreiben, behalten Sie direkte Kontrolle über Hardware und lokale Netzanschlüsse, müssen aber Beschaffung, Wartung, Kapazitätsplanung und die Pflege der Netzwerkregeln selbst koordinieren. Eine allgemeine Cloud-VM ist nicht automatisch ein Ersatz für einen Mac-Runner, wenn Ihr Build eine reale macOS-Umgebung verlangt. Ein gemieteter Remote-Mac kann für Teams interessant sein, die eine zusätzliche oder zeitweise Build-Umgebung benötigen; Eignung und Netzwerkpfad müssen Sie jedoch anhand Ihrer eigenen Proxy-, Firewall-, Datenschutz- und Abnahmeanforderungen prüfen.
MACGPU bietet Informationen zu seinem Mac-Angebot und zu M4-Mietoptionen. Diese Seiten ersetzen keine Prüfung der konkreten Netzwerkerreichbarkeit und belegen keine pauschale Freigabe für Ihre Unternehmensrichtlinien. Wenn Sie eine unabhängige Mac-CI-Umgebung in Betracht ziehen, beziehen Sie die erwarteten Netzwerkzugriffe in Ihre Sicherheitsfreigabe ein und wiederholen Sie denselben Workflow-Abnahmetest, bevor Sie Release-Aufgaben dorthin verlagern.
Für ein Team, das bereits eine stabile, vollständig kontrollierte Mac-Flotte besitzt und dauerhaft hohe Build-Last auf derselben Hardware ausführt, kann der Weiterbetrieb mit eigener Beschaffung die einfachere Wahl sein. Wenn dagegen zusätzliche Kapazität für einen begrenzten Bedarf fehlt oder Sie einen separaten Mac-Build-Pfad erst bewerten möchten, vergleichen Sie die internen Aufwände für Hardwarebeschaffung, Wartung und Regelpflege mit einer zeitlich passenden Remote-Mac-Lösung. Entscheiden Sie nach überprüfbarem Netzwerkzugriff und erfolgreicher Abnahme, nicht nach der Annahme, dass ein anderer Betriebsort Firewallprobleme automatisch beseitigt.