Blocage possible : les transferts de résultats échouent sur Mac CI → vérifiez d’abord si vos règles autorisent chaque hôte individuellement ou le domaine générique publié par GitHub. Si elles sont individuelles, comparez-les à la liste officielle actuelle et ajoutez les hôtes manquants ; si le domaine générique est déjà couvert, ne changez pas la règle avant d’avoir vérifié sa portée et testé un workflow réel.
À lire si vous administrez le pare-feu, le proxy ou le filtrage DNS d’une entreprise et devez décider si les nouveaux hôtes sont couverts. Utile aussi aux responsables de Runner Mac auto-hébergés qui doivent préserver l’accès aux journaux, résumés, artefacts et caches. Pour les responsables IT ou plateforme, ce guide fournit un contrôle d’acceptation et une méthode de suivi des changements.
Mis à jour le 27 octobre 2026 ; informations vérifiées à partir de l’annonce GitHub du 22 octobre 2026, de la documentation de l’API Meta et des exigences réseau des Runner auto-hébergés.
Qualifier le périmètre de la règle avant toute modification
Le changement annoncé concerne des hôtes de stockage blob utilisés par GitHub Actions sur GitHub.com. Il ne modifie ni les étiquettes de Runner, ni le contenu du workflow, ni la configuration du dépôt. GitHub a annoncé l’ajout de nouveaux points de terminaison le 22 octobre 2026 et précise que les organisations utilisant une règle générique couvrant le domaine concerné n’ont normalement pas à ajouter une entrée pour chaque nouvel hôte. Les organisations dont les règles énumèrent les hôtes individuellement doivent, elles, réexaminer leur liste (annonce officielle de GitHub).
Commencez par retrouver la politique effectivement appliquée au réseau du Runner, pas seulement un document d’architecture ou une ancienne demande de changement. Le filtrage peut être défini dans le pare-feu, un proxy, un résolveur DNS, un service de filtrage web ou plusieurs de ces couches à la fois. Une règle autorisée à un endroit peut rester bloquée à un autre.
Distinguez ensuite trois formes de contrôle :
- Noms d’hôte individuels : chaque entrée doit être comparée aux valeurs officielles actuelles. C’est la configuration la plus susceptible d’exiger une modification après l’ajout d’un hôte.
- Domaine générique : la règle peut déjà couvrir les noms ajoutés, mais seulement si sa portée, son interprétation par le produit de sécurité et ses contraintes de résolution correspondent aux domaines annoncés.
- Adresses IP : une règle fondée sur des adresses ne se met pas à jour simplement parce qu’un nom d’hôte est ajouté. Ne déduisez pas les adresses d’une réponse DNS ponctuelle et ne remplacez pas sans examen une règle par une autorisation plus large.
Mesurer la précision de votre liste d’autorisation
Pour décider si la règle doit changer, comparez ce que GitHub publie avec le mécanisme utilisé par votre environnement, puis vérifiez les effets de la règle sur le Runner concerné. Voici une branche de décision applicable avant de soumettre une demande de changement :
- Si la règle autorise déjà le domaine générique pertinent, confirmez que la politique couvre bien le trafic sortant du Runner et qu’aucune couche DNS ou proxy ne restreint les sous-domaines ; si ces vérifications sont concluantes, conservez la règle et passez aux tests de workflow.
- Si la règle contient des noms d’hôte exacts, comparez toutes les entrées à l’annonce et aux données actuelles de l’API Meta ; ajoutez uniquement les valeurs manquantes, après validation par l’équipe chargée de la sécurité réseau.
- Si la politique repose sur des adresses IP, ou si vous ne pouvez pas déterminer la portée du joker, ne remplacez pas la règle par une autorisation générale « pour que cela fonctionne ». Faites préciser le modèle de filtrage par l’équipe réseau, puis documentez et testez l’option la moins permissive qui permet les flux nécessaires.
- Si un test échoue malgré une règle apparemment correcte, suspendez l’élargissement de la politique et séparez les causes : résolution DNS, proxy, refus du pare-feu, identité ou permissions de workflow.
**Point de contrôle :** ne validez pas une demande au seul motif que le nom figure dans un ticket ancien. L’annonce GitHub et l’état actuel de l’API sont les références pour l’inventaire ; vos propres journaux et vos tests déterminent si la politique appliquée laisse effectivement passer le trafic.
Vérifier les hôtes dans l’annonce et l’API Meta
Pour récupérer les valeurs à jour, partez de la documentation officielle de l’API Meta de GitHub, puis consultez la réponse actuelle de l’endpoint Meta. L’annonce du 22 octobre présente les nouveaux groupes d’hôtes associés au stockage blob ; recopiez ces valeurs depuis l’annonce et confrontez-les à la réponse courante, plutôt que de transformer une ancienne liste copiée dans un ticket en référence durable.
L’API Meta peut évoluer. Son rôle est de publier des informations réseau utiles aux intégrations et aux règles de filtrage, pas de certifier la configuration de votre pare-feu. Vérifiez les champs pertinents avec la documentation, conservez la date de consultation et enregistrez la réponse utilisée pour le changement. Ne prenez pas un exemple de réponse documentaire pour un inventaire en temps réel : la documentation de l’API décrit son usage, tandis que l’endpoint fournit l’état consulté à un moment donné.
La lecture doit répondre à des questions concrètes :
- La liste officielle comprend-elle les hôtes nécessaires aux transferts blob utilisés par les workflows de l’entreprise ?
- La règle existante correspond-elle à des noms exacts, à un domaine générique ou à des IP ?
- Le pare-feu applique-t-il réellement cette règle au segment, au proxy et au Runner concernés ?
- La réponse DNS du nom résolu par le Runner est-elle autorisée par les contrôles en place ?
La documentation de l’API Meta et l’annonce consacrée aux points de terminaison du stockage blob doivent être lues ensemble. L’annonce explique le changement précis et la distinction entre listes individuelles et règles génériques ; la documentation aide à interpréter l’API. Si leurs informations semblent différer, ne tranchez pas à partir d’une extraction ancienne : vérifiez l’annonce, l’endpoint actuel et les exigences réseau applicables au type de Runner.
Relier le stockage blob aux fonctions CI réellement utilisées
Une règle de sortie ne doit pas être vérifiée dans l’abstrait. Repérez d’abord quelles fonctions de votre chaîne dépendent des échanges de résultats. GitHub documente les communications réseau nécessaires aux Runner auto-hébergés, ainsi que les exigences applicables à leurs connexions (référence réseau des Runner auto-hébergés). Consultez cette référence pour distinguer les destinations liées à l’exécution Actions des accès aux API, aux dépôts et aux outils de compilation.
Les transferts liés au stockage peuvent intervenir dans le parcours des journaux, des résumés, des artefacts ou des caches. Leur disponibilité ne se confond pas avec l’accès au dépôt ou à l’API GitHub. Un Runner peut donc récupérer le code et lancer Xcode, tout en rencontrant un refus sur le transfert d’un résultat. À l’inverse, une erreur de permission lors de la publication d’un artefact ne prouve pas que l’hôte blob est bloqué.
Examinez les fonctions utilisées par vos équipes, plutôt que de supposer qu’un essai de compilation couvre tout :
- Journaux et résumé : vérifiez que les sorties de l’exécution restent consultables après le travail du Runner. En cas d’absence, recherchez les événements réseau correspondants et distinguez-les d’une erreur de workflow ou de droits.
- Artefacts de workflow : si vos pipelines téléversent des archives, des rapports ou des livrables, vérifiez le téléversement puis la récupération depuis l’interface ou l’étape qui les consomme. La documentation GitHub décrit le fonctionnement des artefacts de workflow.
- Cache de dépendances : si les équipes l’utilisent, validez séparément la restauration et l’enregistrement. Les mécanismes de cache ne doivent pas être assimilés à la publication d’artefacts ; leurs usages et leur documentation sont distincts (documentation du cache de dépendances).
- Accès au code et aux API : consignez-les à part. Un succès ou un échec de ces appels ne suffit pas à conclure sur les points de terminaison de stockage.
Valider le changement dans un workflow Mac représentatif
Après le contrôle de la règle, testez depuis le même environnement réseau que le Runner de production. Un poste développeur situé sur un autre réseau ne constitue pas une validation équivalente. Choisissez un workflow qui exerce réellement les fonctions de votre équipe : compilation iOS ou macOS, génération d’un résumé, publication d’un artefact et, si le pipeline l’utilise, restauration ou écriture du cache.
Procédez de manière à rendre le résultat exploitable :
- Identifiez le périmètre du test : consignez le Runner concerné, le réseau de sortie, la politique examinée et les fonctions exercées. N’inférez pas la couverture d’un Runner depuis un autre segment.
- Lancez une exécution témoin : sélectionnez un workflow représentatif, sans modifier simultanément les permissions, les scripts et les règles réseau. Si plusieurs variables changent à la fois, un succès ne permet pas d’identifier la cause.
- Examinez le résultat des étapes : vérifiez l’accès au journal et au résumé, puis confirmez qu’un artefact attendu peut être envoyé et récupéré. Testez le cache seulement si le pipeline l’utilise réellement.
- Corrélez les événements : rapprochez l’heure de l’exécution des événements du pare-feu, du proxy et du DNS. Notez l’hôte demandé, la décision observée et le résultat de l’étape de workflow ; masquez les secrets et données sensibles dans les preuves partagées.
- Classez l’échec avant de changer la règle : un refus explicite du pare-feu, une résolution DNS impossible, un rejet du proxy ou une erreur de permission exigent des corrections différentes. Si le flux est autorisé mais que le workflow échoue encore, poursuivez l’analyse du côté de l’action ou de la configuration du pipeline.
Pour éviter que le diagnostic ne dérive vers Xcode ou les étiquettes de Runner, utilisez une exécution limitée qui vérifie les transferts indépendamment de modifications de l’outil de compilation. Vous pouvez ensuite relancer le workflow complet de publication pour confirmer que les étapes habituelles sont intactes. Le premier test réduit les variables ; le second valide la chaîne réelle. Gardez les deux résultats liés à la demande de changement.
Organiser la revue à partir d’indicateurs vérifiables
La revue ne doit pas être un rappel vague de « vérifier régulièrement ». Attribuez un propriétaire à l’inventaire des hôtes, définissez les événements déclencheurs et conservez des preuves permettant à un autre administrateur de reproduire la décision. Une modification d’annonce GitHub ou une mise à jour des exigences réseau des Runner doit déclencher une réévaluation ; le résultat d’un contrôle périodique peut aussi révéler une règle devenue incohérente avec l’usage réel.
Dans votre procédure, séparez les éléments suivants :
- Source de l’inventaire : lien vers l’annonce officielle et date de consultation de l’API Meta.
- Politique examinée : type de règle, périmètre réseau, contrôle du proxy ou du DNS et justification de la portée.
- Résultat d’acceptation : identifiant du workflow, fonctions testées, résultat et événements réseau associés.
- Décision : règle conservée ou modifiée, entrées ajoutées, approbateur et éventuelles restrictions compensatoires.
- Prochaine revue : événement qui imposera une nouvelle vérification et équipe responsable de l’effectuer.
Comparer les méthodes de contrôle et leur niveau de preuve
Le tableau ci-dessous aide à décider où consacrer l’effort de vérification. Les appréciations sont qualitatives : elles décrivent le travail de contrôle, pas une garantie de fonctionnement dans votre réseau.
| Méthode de règle | Action après l’annonce | Risque de dérive | Preuve à réunir | Appréciation |
|---|---|---|---|---|
| Hôtes individuels | Comparer la liste déployée à l’annonce et à l’API actuelle ; ajouter seulement les valeurs manquantes | Élevé si l’inventaire n’est pas révisé | Différence documentée et test réel des transferts | Contrôle précis, entretien nécessaire |
| Domaine générique | Vérifier la correspondance effective, les restrictions et la résolution ; ne pas ajouter une entrée redondante sans motif | Dépend de la portée du joker et de la politique du produit | Règle réellement appliquée, trace réseau et workflow concluant | Peu de changements possibles, portée à justifier |
| Adresses IP | Vérifier la source et le mode de maintien de la liste ; ne pas déduire une politique permanente d’une résolution ponctuelle | Important si les IP évoluent ou si la synchronisation est manuelle | Inventaire autoritatif, correspondance de la politique et traces | Exige une gouvernance adaptée au filtrage IP |
Questions fréquentes sur la vérification des hôtes
Faut-il modifier le pare-feu après l’ajout de nouveaux hôtes de stockage blob ?
Cela dépend de la forme de vos règles. Si votre pare-feu autorise déjà le domaine générique indiqué par GitHub, l’annonce précise que l’ajout ne nécessite généralement pas de nouvelle entrée. Si la politique énumère chaque nom d’hôte, comparez-la aux valeurs officielles actuelles et ajoutez uniquement les hôtes manquants. Vérifiez ensuite le résultat dans vos journaux réseau et un workflow représentatif.
Comment vérifier que la liste d’autorisation couvre les nouveaux points de terminaison ?
Comparez les règles appliquées, et non seulement leur documentation, aux informations de l’annonce officielle et à la réponse actuelle de l’API Meta. Contrôlez si la règle est fondée sur un nom exact, un domaine générique ou une adresse IP, puis examinez la résolution DNS et les journaux du pare-feu. Une exécution réussie du workflow permet ensuite de confirmer que le chemin de transfert réellement utilisé est autorisé.
Pourquoi les journaux ou le résumé d’un workflow Mac ne sont-ils pas visibles après la compilation ?
Un transfert bloqué vers un point de terminaison de stockage peut empêcher l’accès à certains résultats, mais ce n’est pas la seule explication possible. Distinguez un refus réseau d’un problème DNS, d’un proxy, d’une permission ou d’une étape de workflow ayant échoué. Examinez les événements réseau à l’heure de l’exécution, puis relancez un cas qui publie un résumé et un artefact afin de localiser le flux défaillant.
À quelle fréquence faut-il réexaminer les hôtes renvoyés par l’API Meta ?
Ne traitez pas une copie exportée de l’API comme une liste permanente. Réexaminez-la quand GitHub annonce une modification des points de terminaison ou met à jour ses exigences réseau, et ajoutez cette vérification à votre revue périodique des règles. Définissez un propriétaire, conservez la réponse datée et reliez chaque changement à un test de workflow ainsi qu’aux journaux de décision du pare-feu.
Si votre Mac CI actuel repose sur des machines achetées et dispersées entre plusieurs équipes, les règles peuvent varier d’un site à l’autre, la maintenance du matériel reste à votre charge et l’extension de capacité implique un cycle d’approvisionnement. Une machine dédiée déjà amortie peut toutefois rester préférable si vous avez besoin d’un environnement stable en permanence ou d’interfaces physiques spécifiques. Si vous devez plutôt mettre en place un environnement Mac distant temporaire ou évaluer une capacité de build séparée, consultez les options de Mac distant proposées par MACGPU et confrontez-les à vos exigences de réseau, d’isolation et d’acceptation. Ne présumez pas que le changement d’hôtes GitHub est couvert sans réaliser vos propres tests : validez la politique appliquée et les transferts sur le réseau choisi avant de l’intégrer à un pipeline de publication. Vous pouvez également examiner les informations de MACGPU sur ses solutions Mac, puis comparer ces options à un achat direct ou à un environnement déjà administré par votre équipe.