Le même label GitHub Actions peut désormais tourner sur AWS
Un job peut échouer lors d’une connexion externe sans changement de YAML. Le 28 octobre, GitHub a annoncé une capacité Linux sur AWS en plus d’Azure. Le label peut rester identique alors que l’adresse de sortie change.
Davantage de machines derrière les mêmes labels
Sont concernés les runners Linux standard à 2 et 4 cœurs et les larger runners compatibles de ces tailles sans configuration spécialisée. Windows et les réseaux privés sont exclus. Free, Pro et Team y passent automatiquement ; Enterprise Cloud peut activer AWS dans Actions > Hosted compute cloud providers.
GitHub répartit les jobs éligibles entre fournisseurs disponibles sans modifier labels ou syntaxe. L’objectif concerne les attentes liées à la capacité et la résilience, pas une accélération garantie de chaque job ni une double exécution sur deux clouds.
Un échec qui semble intermittent
Imaginons une API de déploiement n’acceptant que les adresses Azure. Un workflow identique pourrait passer depuis Azure et être refusé depuis une autre sortie. GitHub cite aussi Microsoft Entra Conditional Access. Il s’agit d’un exemple, pas d’un incident vécu.
Avant de renouveler les jetons, comparer heure, destination, IP source et politique appliquée. L’attente d’une machine et un refus d’authentification après démarrage sont deux étapes distinctes. Une capacité accrue ne corrige pas une règle d’accès.
Une liste d’IP contient des plages
Le point de départ est actions dans GET https://api.github.com/meta. La documentation REST demande les valeurs actuelles plutôt que ses exemples. Notre test local Python ipaddress utilise 192.0.2.0/24, réservé à la documentation : .10 et .200 appartiennent à cette plage, contrairement à 198.51.100.10. Ce ne sont pas de vraies IP de runners.
Autoriser toutes les plages ne convient pas partout. La référence déconseille les nombreuses plages standard pour l’accès aux ressources internes et propose des larger runners à IP statique ou des runners autohébergés. Authentification et moindre privilège restent nécessaires.
Un label stable, une hypothèse différente
Situer d’abord l’échec avant ou après le démarrage, puis confronter plages actuelles et politiques effectives. Si une sortie fixe est indispensable, choisir le runner adapté. Un label ne doit pas tenir lieu d’identité du fournisseur cloud.