Que faire si les tâches du runner macOS de GitHub Actions sont en attente ? Liste de validation d’un runner autogéré 2026

Une tâche GitHub Actions reste en attente alors qu’un runner macOS semble disponible.

Cette semaine, vérifiez d’abord les étiquettes, l’état du runner, les autorisations et les ressources demandées. N’ajoutez un runner macOS autogéré que si le manque de capacité ou le besoin d’un environnement de maintenance fixe est confirmé ; validez ensuite son acceptation, sa construction, son nettoyage et sa reprise avec un vrai flux de travail.

Ce guide s’adresse aux personnes qui maintiennent des pipelines iOS ou macOS, administrent GitHub Actions ou préparent un runner autogéré. Vous pourrez distinguer un défaut de routage d’une panne de compilation et décider si l’ajout d’une machine répond réellement à la cause.

En attente ou déjà lancé : séparer les symptômes

Avant de modifier l’infrastructure, notez l’identifiant du flux de travail, le nom du travail concerné, les étiquettes demandées et les dernières lignes de journal disponibles. Cette trace évite de confondre trois situations : le travail n’a pas été attribué, un runner n’a pas pris le travail, ou le travail a démarré puis a échoué. Ces situations ne réclament pas le même correctif.

Symptôme visible	Où regarder	Première hypothèse à tester
Le travail reste « en attente » et aucun journal d’étapes n’apparaît	Exécution du flux de travail, critères `runs-on`, groupes et étiquettes du runner	Aucun runner éligible n’est disponible ou autorisé
Le runner apparaît hors ligne ou ne prend pas de travail	État dans les paramètres GitHub, processus du runner, réseau et journaux du service	Le runner n’est pas joignable ou son service n’est pas actif
Les étapes commencent, puis une commande échoue	Journaux de la tâche, version de Xcode, dépendances, signature et secrets	La planification fonctionne ; l’échec concerne la construction ou son environnement

Pourquoi une tâche GitHub Actions peut-elle rester en attente ? Une file d’attente ne prouve pas à elle seule un manque de machines. GitHub route les tâches en fonction des critères de sélection, des étiquettes et des règles d’accès ; un runner en ligne, mais non admissible pour ce travail, ne le prendra pas. Commencez donc par comparer la demande exacte du flux de travail avec la configuration réelle du runner, au lieu de déduire la cause de l’écran d’attente. Les règles de routage sont décrites dans la documentation des runners autogérés et dans le guide sur l’utilisation d’un runner depuis un flux de travail.

Gardez aussi séparés le statut affiché et les journaux détaillés. Si les informations visibles ne permettent pas de comprendre pourquoi une tâche n’est pas prise, activez la journalisation de débogage avant de relancer le diagnostic ; les étapes d’activation sont décrites dans la documentation GitHub sur les journaux de débogage. Ne supprimez pas les traces utiles en multipliant les essais sans noter ce qui a changé.

Runner admissible ou runner simplement en ligne : comparer les causes

Un runner peut être démarré sans pouvoir accepter le travail visé. Vérifiez que les valeurs de runs-on correspondent aux étiquettes affectées au runner. GitHub attribue par défaut trois catégories d’étiquettes à un runner autogéré : self-hosted, le système d’exploitation et l’architecture. Les valeurs disponibles et la manière d’ajouter des étiquettes sont décrites dans le guide sur l’attribution d’étiquettes aux runners autogérés.

Vérification	Runner admissible	Runner en ligne, mais non admissible
`runs-on`	Toutes les étiquettes demandées sont présentes	Une étiquette manque, diffère par sa valeur ou ne correspond pas à l’architecture
Portée	Le runner ou son groupe peut servir le dépôt concerné	Le runner existe, mais le dépôt n’est pas autorisé à l’utiliser
Test	Un petit travail de diagnostic est attribué et démarre	Le travail reste en attente ou ne cible aucun runner éligible

Les étiquettes ne sont pas le seul filtre. Les runners peuvent être organisés en groupes, et les règles d’accès déterminent quels dépôts ou organisations peuvent les utiliser. Examinez cette portée avant de modifier une machine : la documentation sur les accès aux groupes de runners explique les autorisations et les considérations de sécurité associées.

Pour vérifier la configuration sans lancer immédiatement une compilation iOS lourde, créez un flux de travail de diagnostic minimal qui demande les mêmes étiquettes et le même groupe que le travail bloqué. Faites-lui exécuter une commande sans secret ni artefact sensible, puis vérifiez qu’il démarre effectivement sur le runner attendu. Cette vérification est plus probante que le seul statut « en ligne » : elle confirme le chemin réel entre le dépôt, les règles d’accès, le routage et la prise en charge du travail.

Un runner est en ligne, mais le flux de travail ne démarre pas : que vérifier ? Comparez les étiquettes, le groupe sélectionné et les autorisations du dépôt, puis contrôlez les ressources demandées dans runs-on. Ne supposez pas que l’enregistrement du runner donne automatiquement accès à tous les dépôts. Si le test minimal échoue, corrigez d’abord la configuration ou les droits ; ajouter une seconde machine reproduirait souvent le même défaut de routage.

Runner actif ou service interrompu : vérifier la reprise

Quand le travail ne part pas, consultez l’état du runner dans les paramètres GitHub et comparez-le au processus réellement exécuté sur l’hôte. Vérifiez ensuite la connectivité réseau et les journaux du service. Un statut ancien ou une machine qui s’est déconnectée après une interruption ne constitue pas une capacité disponible. Les étapes de suivi et de diagnostic sont détaillées dans la documentation de surveillance des runners autogérés.

L’installation doit être vérifiée après les événements qui interrompent le service, et pas uniquement juste après sa mise en place. Prévoyez un test après redémarrage, un contrôle après une perte de réseau simulée dans un cadre maîtrisé et une alerte lorsque le runner attendu cesse d’être disponible. Définissez aussi qui reçoit l’alerte, comment l’état est confirmé et à quel moment le runner est remis en service. Sans responsable ni procédure de reprise, une alerte isolée ne rétablit pas la capacité de construction.

Le système d’exploitation et l’architecture doivent également être compatibles avec l’usage prévu. La documentation GitHub indique macOS 11 ou version ultérieure parmi les plateformes prises en charge pour les runners autogérés ; elle présente également les architectures utilisables. Vérifiez la liste officielle des plateformes et exigences des runners au moment de l’installation : ne transformez pas cette indication en garantie qu’une version donnée de Xcode fonctionnera sur n’importe quel macOS. Pour ce point, confrontez la version de Xcode envisagée à la matrice des exigences système publiée par Apple.

Travail en cours ou travail échoué : isoler la compilation

Si des étapes apparaissent dans les journaux, la tâche a été prise en charge : la file d’attente n’est probablement plus le sujet à traiter. Enregistrez le résultat comme un incident de construction distinct. Comparez les versions de Xcode et des outils, la disponibilité des dépendances, les variables nécessaires à la signature et l’accès aux secrets. Une dépendance inaccessible ou un certificat absent peut faire échouer le même projet alors que le routage du runner est parfaitement fonctionnel.

Étape de validation	Vérification concrète	Interprétation
Environnement	Le flux de travail relève la version de macOS et les outils effectivement présents	Un écart avec l’environnement attendu oriente vers une incompatibilité
Dépendances	Les outils de construction et les dépendances sont accessibles depuis le runner	Un échec de téléchargement ou de résolution n’est pas un défaut de capacité
Signature	Les éléments nécessaires sont disponibles uniquement dans le contexte de travail prévu	Une erreur de signature doit être traitée comme un problème de configuration ou d’accès
Résultat du travail	Les étapes démarrent, puis une commande renvoie une erreur	Le runner a accepté le travail ; examinez la commande et son environnement

Pour les projets audio, vidéo ou de création, ajoutez à cette vérification les outils auxiliaires et les ressources que le pipeline appelle réellement. Un projet qui assemble une application, traite des médias ou produit des rendus peut dépendre d’outils différents de ceux du simple contrôle de compilation. Vérifiez leur présence dans le même flux de travail qui échoue ; évitez de conclure qu’un runner est sous-dimensionné avant d’avoir identifié une consommation ou une limite mesurable.

La règle de triage est simple : si les journaux d’étapes sont présents, traitez d’abord la première commande en échec ; si le travail n’est jamais attribué, revenez au routage, aux accès et à la disponibilité. Cette séparation évite de multiplier les runners pour compenser un mauvais secret ou une version d’outil incohérente.

Fin de tâche ou résidus sensibles : contrôler l’isolation

Un travail terminé ne signifie pas nécessairement que l’environnement est prêt pour le suivant. Vérifiez ce qui reste dans le répertoire de travail, les fichiers temporaires, les journaux locaux et les éléments utilisés pour la signature. Identifiez les fichiers réutilisés par le cache et distinguez-les de ceux qui peuvent contenir des secrets ou des données propres à un dépôt.

Définissez le nettoyage à partir du risque, pas seulement du confort. Un cache de dépendances peut réduire des téléchargements répétés, mais il ne doit pas mélanger des fichiers privés entre des flux de travail qui ne devraient pas partager leur état. Les fichiers temporaires contenant des certificats, des jetons ou des configurations sensibles doivent avoir un cycle de vie explicite : création dans le contexte requis, suppression en fin de travail et révocation d’un secret lorsqu’une exposition est suspectée.

Comment valider une migration de runner macOS ? Faites exécuter au nouveau runner un travail de diagnostic, puis une construction représentative du projet et enfin un contrôle de nettoyage. Vérifiez que les mêmes protections d’accès s’appliquent après migration, que les journaux permettent d’identifier les échecs et qu’un redémarrage ne laisse pas le runner inutilisable. Ne considérez pas la migration terminée au seul motif que la machine apparaît dans la liste.

Acceptation en cinq volets : choisir selon les résultats

Utilisez cette liste avant de déclarer le runner prêt. Chaque case doit être confirmée par une exécution ou une vérification observable, et non déduite de la configuration seule.

[ ] Prise en charge : un travail de diagnostic avec les étiquettes prévues est effectivement attribué au runner cible.
[ ] Construction : une tâche représentative du projet atteint les étapes de compilation et permet de distinguer un échec d’outil d’un échec de routage.
[ ] Alerte : une indisponibilité détectable déclenche une alerte compréhensible, adressée à une personne ou à une équipe responsable.
[ ] Reprise : après un redémarrage contrôlé, le runner revient dans un état vérifiable et peut reprendre un travail.
[ ] Nettoyage : les fichiers temporaires et les éléments sensibles suivent la règle de conservation ou de suppression définie.

Prenez votre décision avec les conditions suivantes :

Si le test de prise en charge échoue, corrigez les étiquettes, le groupe ou les autorisations avant d’ajouter des machines.
Si le runner est indisponible après un redémarrage ou une interruption, réparez son lancement automatique, sa connectivité et son alerte avant de le déclarer opérationnel.
Si le travail démarre mais échoue sur une commande, conservez le diagnostic dans le registre des problèmes de construction et vérifiez outils, dépendances et signature.
Si la construction réussit mais laisse des résidus sensibles, bloquez le partage avec d’autres flux de travail jusqu’à ce que le nettoyage et l’isolation soient validés.
Si les cinq contrôles passent et que le blocage vient d’une capacité réellement insuffisante ou d’un environnement macOS fixe, évaluez un runner autogéré ; sinon, gardez la solution actuelle et corrigez son point faible.

Cette décision évite de confondre « ajouter une machine » et « réparer le pipeline ». Un runner supplémentaire ne corrige ni une étiquette absente, ni une autorisation restrictive, ni une dépendance en panne. Documentez le résultat de chaque essai avec l’identifiant du flux de travail, le runner ciblé, l’état observé et la cause retenue : la prochaine personne pourra reprendre l’enquête sans recommencer à zéro.

Capacité actuelle ou Mac dédié : arbitrer sans déplacer le problème

Votre dispositif actuel peut être limité par une capacité partagée, par un environnement qui change entre deux constructions ou par une maintenance difficile à planifier. Un runner autogéré peut donner davantage de contrôle sur l’environnement macOS, mais il ajoute aussi la responsabilité de maintenir le service, de surveiller sa disponibilité et de protéger les fichiers laissés par les travaux. Si le problème est seulement une règle de routage, ces coûts ne vous apporteront aucun bénéfice.

Si vous avez besoin d’un environnement macOS temporaire pour valider une migration ou absorber une charge ponctuelle, comparez d’abord votre travail réel avec les conditions d’accès et le cycle de vie de la machine. Pour clarifier les modalités d’accompagnement avant un essai, consultez également le centre d’aide de Hashvps. Vous pouvez ensuite examiner les détails des offres Mac de Hashvps et demander confirmation de la compatibilité de votre mode d’accès et de votre flux de travail avant toute décision. Louer un Mac n’est pertinent que si l’environnement proposé répond à vos exigences ; si vous avez besoin d’un matériel toujours disponible, d’interfaces physiques spécifiques ou d’une exploitation durable à charge stable, comparez aussi l’achat et la maintenance d’une machine dédiée. Remédiez d’abord aux étiquettes ou aux permissions si elles sont en cause.