GitHub Actions macOS Runner : que faire si la file est trop longue ? Décider d’augmenter la capacité en 2026
Un job iOS reste en attente dans GitHub Actions, ou disparaît avant même d’afficher la première étape ?
Solution la plus rapide : ne relancez pas en boucle et n’ajoutez pas immédiatement une machine. Vérifiez d’abord si le job a commencé, puis séparez trois pistes : concurrence du workflow, Runner autonome indisponible ou problème de capacité et de service côté GitHub. Si les builds macOS de votre dépôt restent durablement dans la file, évaluez un Runner Mac autonome en parallèle. Il ne réparera pas le service de planification de GitHub.
Cet article s’adresse aux développeurs indépendants dont les builds ou publications iOS attendent dans la file, aux petites équipes dont la CI ralentit les intégrations, et aux personnes qui administrent un Runner autonome et doivent vérifier son état, ses étiquettes et la réception des jobs.
Dernière mise à jour : 11 novembre 2026. Les limites, mécanismes et pistes de diagnostic ont été revérifiés dans la documentation officielle des limites GitHub Actions, les instructions GitHub sur les Runner hébergés, la page d’état du service GitHub et la discussion de la communauté citée ci-dessous.
File d’attente ou build lent : deux diagnostics différents
Un job en attente n’a pas encore commencé à exécuter ses étapes. Un build lent, lui, a été attribué à un Runner et a démarré. La durée totale affichée dans l’historique ne suffit donc pas à identifier la cause : elle peut inclure l’attente, la préparation de l’environnement et le travail du projet.
Ouvrez l’exécution concernée et consultez les événements du job, sa chronologie et ses journaux. Repérez le premier indice prouvant que le Runner a pris le travail en charge : une première étape exécutée, une commande ou un message d’initialisation. Si rien ne commence, enquêtez sur l’attribution et la file. Si le job affiche déjà des étapes, cherchez plutôt une erreur d’outil, de dépendance, de signature ou de test.
La limite de durée d’exécution est un autre sujet. La documentation fixe à 360 minutes le délai maximal d’un job ; ce seuil concerne l’exécution, pas une garantie de délai pour être placé sur un Runner. Un job qui dépasse ce seuil et un job qui attend avant sa première étape ne se diagnostiquent pas de la même façon (limites et durées des jobs).
Pour examiner une exécution depuis le terminal, la commande suivante permet de récupérer son journal :
gh run view ID_DU_RUN --log
Dans la sortie, cherchez la première étape réellement lancée, les messages liés au Runner et l’état final du job. Si le journal ne contient aucune étape, gardez cette information comme indice de non-dispatch ; elle ne prouve pas à elle seule une panne générale.
Le premier tri : état du service, Runner et concurrence
Quand seuls les jobs macOS semblent concernés, commencez par comparer leur état aux autres travaux du dépôt. Si les jobs Linux ou Windows avancent alors que les jobs macOS restent bloqués, cela justifie une vérification ciblée des Runner macOS. Cela ne suffit toutefois pas à établir que GitHub connaît un incident : les files et limites peuvent dépendre du compte, de la plateforme et du contexte d’exécution.
Consultez la page d’état officielle, puis confrontez ses avis à l’heure de l’incident et aux événements du job. La documentation GitHub décrit les mécanismes généraux des Runner hébergés, mais une file persistante dans un dépôt ne signifie pas automatiquement que la capacité globale est saturée. Les règles de disponibilité et les limites publiées sont détaillées dans la référence officielle des limites Actions.
Des utilisateurs ont rapporté, dans une discussion publiée entre le 3 et le 9 novembre 2026, des messages de capacité ou des échecs de jobs macOS arm64 avant l’exécution des étapes. Ce sont des signalements individuels, pas une confirmation d’une panne généralisée, d’une cause précise ou d’une correction officielle (discussion communautaire sur les jobs macOS arm64). Utilisez-les comme piste à comparer aux journaux de votre dépôt, jamais comme diagnostic suffisant.
| Ce que montre le job | Piste prioritaire | Vérification suivante |
|---|---|---|
| Aucune étape n’a commencé | Attribution, file ou service | État du service, messages de capacité et règles de concurrence |
| Le job est attribué, mais l’environnement ne démarre pas | Initialisation du Runner ou de l’environnement | Journaux de préparation et messages d’erreur de démarrage |
| Des étapes ont démarré, puis échoué | Workflow, outil ou projet | Première étape en erreur, version de Xcode, dépendances et configuration |
| Un Runner autonome reste sans job | État ou correspondance du Runner | Disponibilité, occupation, étiquettes et groupe |
Trois causes à départager avant d’augmenter la capacité
Première vérification : le workflow retient-il lui-même ses jobs ?
Inspectez le fichier de workflow pour repérer concurrency. Dans un même groupe, la règle documentée permet un job en cours et un job en attente ; un nouveau job peut remplacer celui qui attend déjà. Une série de commits ou de déclenchements rapprochés peut donc produire des annulations qui ressemblent à une file macOS défaillante. Vérifiez la documentation sur la concurrence des workflows.
Examinez aussi les matrices de tests. Une matrice peut multiplier les tâches macOS, même si certaines vérifications sont identiques ou peuvent s’effectuer sur un autre environnement. Repérez les déclenchements en double, par exemple lorsque le même changement lance plusieurs événements de workflow. Vous pouvez faire passer d’abord les vérifications qui ne nécessitent pas macOS, regrouper des validations répétitives ou limiter les combinaisons réellement nécessaires.
Cela peut diminuer la demande créée par votre dépôt, mais ne garantit pas de contourner une limite de capacité ou un incident côté service. Conservez les contrôles indispensables à la qualité et à la publication.
Deuxième vérification : le Runner autonome peut-il accepter le job ?
Un Runner autonome inactif ne signifie pas forcément qu’il est correctement prêt à recevoir les tâches attendues. Contrôlez son état dans les paramètres du dépôt ou de l’organisation, vérifiez s’il est déjà occupé et comparez les étiquettes demandées dans le workflow aux étiquettes attribuées à la machine. Si un Runner group est utilisé, confirmez que le dépôt et le workflow ont le droit de l’utiliser.
Les instructions de surveillance et de dépannage des Runner autonomes recommandent de vérifier l’état et les journaux du service. Les règles d’utilisation des Runner autonomes donnent le cadre des groupes et des étiquettes. Distinguez le cas où la machine n’est pas disponible de celui où elle a reçu le job, mais échoue ensuite à initialiser l’environnement.
| Indice observé sur le Runner autonome | Interprétation possible | Action de contrôle |
|---|---|---|
| Runner hors ligne | Service arrêté, machine inaccessible ou problème de connexion | Contrôler le service et ses journaux |
| Runner en ligne, sans job attribué | Étiquette, groupe, permissions ou concurrence à vérifier | Comparer les règles du workflow et du Runner |
| Job reçu, mais aucune étape utile ne démarre | Problème de préparation ou de configuration locale | Examiner le journal du Runner et l’environnement |
| Job démarré puis en échec | Défaut d’exécution, de dépendance ou de projet | Identifier la première étape en erreur |
Un Runner hors ligne et un job hébergé qui attend dans une file sont deux symptômes distincts. Ajouter une machine sans vérifier les étiquettes et le groupe peut simplement créer un Runner de plus qui ne reçoit pas le travail.
Troisième vérification : les tâches macOS sont-elles plus nombreuses que nécessaire ?
Comparez les déclenchements et les jobs réellement en attente. Une augmentation de la file en période de commits rapprochés peut venir du nombre de tâches demandées par votre propre CI. C’est différent d’un Runner prêt qui ne reçoit pas le job, et différent d’un Runner hébergé indisponible. Dans ce dernier cas, réorganiser les étapes du workflow n’agit pas sur la capacité du service.
La documentation de dépannage des workflows aide à relier les événements, les journaux et les erreurs d’exécution (diagnostiquer les problèmes de workflows). Appliquez ces contrôles avant de modifier la configuration de publication ou les secrets : un problème d’attribution ne justifie pas, à lui seul, de refaire la signature iOS.
Attendre, ajuster le workflow ou ajouter un Mac Runner ?
Le choix dépend de l’endroit où le job s’arrête et de la répétition du problème. Les trois options ci-dessous ne sont pas interchangeables. Une nouvelle machine peut aider une file créée par les besoins de votre projet si elle est intégrée correctement ; elle ne corrige ni une panne de planification GitHub ni une erreur dans le workflow.
| Situation confirmée | Réponse adaptée | Ce qu’elle ne résout pas |
|---|---|---|
| Incident ou signal de capacité côté GitHub | Conserver les journaux, suivre l’état officiel et relancer quand la situation le justifie | N’accélère pas le service côté GitHub |
| Concurrence, déclenchements répétés ou matrice trop large | Réviser les groupes, déclencheurs et tâches macOS réellement indispensables | Ne garantit pas une place si la capacité hébergée est limitée |
| Runner autonome hors ligne ou mal étiqueté | Rétablir le service, corriger les étiquettes ou le groupe et tester l’attribution | N’ajoute pas de capacité tant que le Runner ne reçoit pas de job |
| Besoin régulier d’exécuter davantage de builds macOS propres au dépôt | Évaluer un Mac autonome comme voie parallèle | Ne supprime pas les erreurs du workflow ni les limites du service distant |
Si l’état officiel signale un incident ou si les journaux montrent un problème de capacité côté Runner hébergé, archivez les éléments utiles et suivez les mises à jour avant de multiplier les relances. Une relance répétée peut ajouter du bruit et ne crée pas de capacité disponible. Si le problème apparaît surtout lors de rafales de tâches de votre dépôt, commencez par réduire les doublons ou revoir la répartition des validations.
Si votre équipe possède déjà un Runner autonome, corrigez d’abord son état, ses étiquettes et l’accès au groupe. S’il est correctement configuré mais que les jobs iOS continuent de s’accumuler à cause d’un besoin régulier en exécution macOS, un Mac supplémentaire peut constituer une voie parallèle. Cette décision se prend après un essai sur votre propre projet, pas à partir d’une promesse de délai ou de performance.
Cinq étapes pour valider une solution de repli
Une nouvelle machine n’est utile que si le workflow lui attribue réellement les tâches prévues et si le résultat convient à votre processus de livraison. Avant de déplacer une publication dessus, procédez par étapes :
- Choisissez un job représentatif. Prenez un build ou un test iOS dont les exigences sont connues. Notez le type de tâche, les dépendances et les conditions de signature nécessaires.
- Confirmez la réception du job. Vérifiez que l’exécution apparaît sur le Runner prévu et qu’elle n’est pas restée en attente à cause d’une étiquette ou d’un groupe incompatible.
- Contrôlez l’environnement Xcode demandé. Confirmez que le workflow sélectionne l’environnement attendu par le projet. Ne déduisez pas sa disponibilité du seul fait que la machine est un Mac.
- Exécutez le build ou les tests représentatifs. Examinez la première étape en échec, les journaux et le résultat obtenu. Un démarrage de job ne suffit pas à valider la compilation.
- Vérifiez les éléments de livraison. Pour une tâche de publication, contrôlez le résultat produit et les étapes de signature ou de transfert exigées par votre processus, avant d’en faire la voie principale.
Gardez une trace de la réception du job, de l’environnement réellement sélectionné et du résultat de build ou de test. Cela permet de comparer la solution de repli à la configuration existante sans confondre attribution, initialisation et exécution. Les indications générales sur les Runner hébergés sont disponibles dans la documentation GitHub correspondante ; elles ne constituent pas une preuve qu’une configuration particulière est disponible sur une machine donnée.
Si l’équipe envisage un Mac distant, elle peut consulter les options de Mac mini distant et vérifier ensuite les modalités adaptées à son usage dans les offres de location Mac. Ces pages ne remplacent pas un test de Runner : c’est le workflow réel qui doit confirmer la réception, le choix de l’environnement et la réussite du build.
Questions fréquentes
Pourquoi un job macOS reste-t-il en attente alors que d’autres jobs démarrent ?
Comparez les plateformes et les jobs du même workflow. Puis vérifiez les limites et l’état du service, ainsi que la configuration de concurrence. Si le job demande un Runner autonome, examinez aussi ses étiquettes, son groupe et son état en ligne. Une différence entre jobs macOS et non macOS est un indice de diagnostic, pas une preuve de panne générale.
Que vérifier si un job est annulé avant sa première étape ?
Recherchez d’abord un événement d’attribution du Runner et un message d’initialisation dans la chronologie ou les journaux. En leur absence, examinez l’état du service et la concurrence du workflow. Pour un Runner autonome, vérifiez l’occupation et la correspondance des étiquettes. Ne corrigez pas le code de build tant que les étapes n’ont pas commencé.
Comment distinguer une attente causée par la concurrence du workflow ?
Repérez la clé concurrency et observez les jobs du même groupe : un job peut être en cours et un autre en attente, lequel peut être remplacé par un nouveau job. Comparez cette chronologie aux déclenchements et aux matrices. Si aucun groupe ne bloque les exécutions et que le Runner ne prend pas le job, poursuivez sur la piste de l’attribution ou du service.
Un Runner Mac autonome est-il une solution à une file de builds iOS ?
Il peut ajouter une voie d’exécution pour les jobs de votre dépôt, à condition d’être en ligne, autorisé et associé aux bonnes étiquettes. Il ne corrige pas une défaillance de planification côté GitHub. Testez un workflow réel et vérifiez l’environnement Xcode et le résultat avant de lui confier les tâches de publication.
Si le diagnostic révèle plutôt un manque durable de capacité Mac dans votre propre chaîne iOS, une exécution macOS dédiée peut éviter de dépendre uniquement des créneaux partagés par le workflow hébergé. Elle ajoute toutefois des tâches d’administration et ne supprime ni les limites de GitHub, ni les erreurs de configuration, ni les problèmes du projet. Pour une machine nécessaire en continu et à charge stable, comparez aussi le coût d’un Mac détenu en propre ; pour un besoin temporaire ou une validation avant engagement, la location distante de SFTPMAC permet d’évaluer le fonctionnement avec votre workflow réel. Consultez les options, puis décidez seulement après avoir validé l’attribution du job et le build.