Quels indicateurs de supervision pour la CI Mac d’entreprise ? Liste de validation 2026

Traitez séparément la disponibilité du Mac, celle du Runner, l’exécution de la tâche et la réussite de la publication. Ces états répondent à des questions différentes. Un tableau de bord qui affiche seulement un voyant vert peut masquer un Runner sans travail, une tâche en échec ou un résultat de test absent.

La documentation GitHub distingue les statuts du Runner et précise comment surveiller ou dépanner les Runners auto-hébergés (états et diagnostic des Runners). Pour une supervision utile, faites suivre chaque signal jusqu’à une preuve exploitable : l’hôte associé, le travail concerné et ses éléments de diagnostic.

Ne regroupez pas ces colonnes sous un indicateur unique de « santé ». Gardez plutôt un état synthétique pour le tableau de bord, avec un lien vers le détail de l’exécution. En cas d’incident, l’opérateur doit pouvoir partir de l’alerte et retrouver le nœud, le Runner, l’identifiant de tâche, les étapes de compilation et les preuves disponibles.

Une CI Mac est également plus large qu’un Runner GitHub Actions. La même logique s’applique à un autre ordonnanceur : distinguez la machine, l’agent, le travail, l’artefact produit et les éléments qui attestent son résultat. Le nom des champs varie selon l’outil ; la relation entre les objets reste un critère d’acceptation.

Pour expliquer un délai ou un échec, réunissez les changements d’état de l’exécution, les tâches qui la composent et les journaux de chaque tâche. Les API GitHub séparent les ressources des exécutions de flux de travail et celles des tâches (API des exécutions, API des tâches). Cette distinction aide à déterminer si le retard se situe avant l’attribution d’un travail, au démarrage du Runner ou au cours d’une étape de compilation.

Une exécution peut être en attente tandis qu’un Mac répond normalement. Une tâche peut démarrer puis échouer alors que le Runner reste connecté. À l’inverse, un travail peut réussir sans que l’équipe puisse retrouver le résultat de test ou l’artefact attendu. Enregistrez séparément les événements pertinents : attente, démarrage, fin, échec, annulation et progression des étapes disponibles. N’interprétez pas un état isolé comme une mesure de la performance globale.

Comparez les tendances de durée et d’échec à votre propre historique. Un délai inhabituel peut signaler une file saturée, un problème de téléchargement, un test instable ou une ressource hôte insuffisante. Sans référence issue des projets de l’équipe, fixer une durée maximale arbitraire risque de déclencher des alertes sans aider au diagnostic.

Pour GitHub Actions, le parcours de supervision doit permettre d’ouvrir les journaux de l’exécution et d’isoler ceux de la tâche concernée. La documentation explique comment consulter les journaux des flux de travail (consultation des journaux GitHub Actions). Vérifiez les droits d’accès et le comportement de rétention utilisés par votre organisation : une adresse de journal visible dans un tableau de bord n’est pas une preuve que les personnes d’astreinte peuvent réellement lire le contenu.

Surveillez les ressources et l’environnement qui peuvent expliquer un symptôme observé : processeur, mémoire, espace disque, réseau, version de Xcode et présence des dépendances nécessaires. La liste seule ne suffit pas. Pour chaque mesure, documentez le défaut qu’elle aide à identifier, le nœud auquel elle se rapporte et la période correspondant à l’exécution.

La pression mémoire peut, par exemple, coïncider avec une compilation interrompue ou un ralentissement ; elle doit être rapprochée des événements du processus et des journaux plutôt que traitée comme une cause certaine. Apple décrit les informations de mémoire affichées dans Moniteur d’activité, dont la pression mémoire (indicateurs mémoire de Moniteur d’activité). N’en déduisez pas un seuil universel pour votre parc : vérifiez les incidents, les charges et les mesures observées sur vos propres projets.

Avant de déclencher une alerte sur une valeur de processeur, de mémoire ou de disque, confirmez qu’elle correspond à un incident que votre équipe sait expliquer. Un seuil sans contexte crée du bruit ; un signal relié à une tâche et à un journal oriente l’intervention.

Pour Xcode, consignez l’environnement réellement employé par le travail : version disponible, commande utilisée, schéma ou cible si cela aide à reproduire l’échec, et résultat produit. Les références Apple décrivent les commandes Xcode utilisables depuis la ligne de commande (référence des outils en ligne de commande Xcode). Votre contrôle d’environnement doit vérifier ce que la chaîne de compilation exige effectivement, pas seulement la présence de l’application Xcode.

La supervision réseau doit aussi rester concrète. Un hôte peut être joignable depuis un poste d’administration sans pouvoir accéder aux dépendances, dépôts ou services sollicités par une tâche. Reproduisez les contrôles depuis le contexte du Runner et enregistrez les échecs pertinents avec l’identifiant de la tâche. Ne confondez pas le succès d’un test de connectivité ponctuel avec la disponibilité de bout en bout pendant une compilation.

Une validation pertinente utilise une chaîne iOS représentative de la charge de production, et non un contrôle isolé qui se contente de confirmer qu’un processus tourne. Préparez une compilation réussie et un scénario d’échec reproductible. Vous vérifierez ainsi que les mêmes indicateurs servent à suivre le fonctionnement normal et à réduire le temps de diagnostic.

1. Définissez le périmètre de l’essai. Notez le dépôt, le flux de travail, le nœud prévu, les étiquettes du Runner, les étapes de compilation et le résultat attendu. Précisez qui reçoit les alertes. Évitez d’inclure des secrets dans les captures ou les journaux de validation.

2. Vérifiez les états du contrôle et du Runner. Comparez l’état rapporté par GitHub à la vue du service sur le Mac. Confirmez que l’étiquette et le groupe du Runner permettent le routage prévu. Si un Runner est en ligne mais qu’aucun travail ne lui est attribué, inspectez d’abord les critères de routage, la file d’attente et l’état d’occupation. Ne concluez pas à une panne de la machine à partir du seul manque de travail.

3. Suivez une exécution de bout en bout. Lancez le flux de travail représentatif et conservez ses identifiants d’exécution, de tâche et de Runner. Vérifiez que l’équipe peut distinguer l’attente, le démarrage, les étapes exécutées et l’issue finale. Comparez ces informations au journal accessible depuis le système de CI ; consignez les écarts plutôt que de reconstruire l’histoire à partir d’alertes déconnectées.

4. Rapprochez les ressources du travail. Relevez l’état du Mac, la mémoire, l’espace disque, la connectivité et l’environnement Xcode pendant l’exécution. Assurez-vous que l’horodatage et l’identifiant du nœud permettent de comparer les mesures à l’étape fautive. Si une métrique ne contribue pas à expliquer les défauts réellement rencontrés, reconsidérez son alerte ou son niveau de priorité.

5. Provoquez un défaut contrôlé. Choisissez un échec sans risque pour la production, par exemple un test qui échoue de manière prévue dans un environnement de validation. Vérifiez que la tâche passe à un état d’échec, que l’alerte est reçue et que ses liens conduisent à la bonne exécution et aux bons journaux. Un message « échec CI » dépourvu de contexte ne suffit pas à satisfaire ce contrôle.

6. Vérifiez la conservation des preuves. Demandez à une personne qui n’a pas lancé le travail de retrouver ses journaux, son résultat de test et les informations de l’environnement depuis l’alerte. Notez les droits manquants, les chemins ambigus ou les résultats impossibles à relier à une tâche. Si le contrôle échoue, corrigez le parcours avant de déclarer la supervision opérationnelle.

Un échec de test est plus facile à trier lorsqu’il est relié au journal de la tâche et au paquet de résultats correspondant. Avec xcodebuild, le résultat de test peut être enregistré dans un paquet de résultats. Apple explique comment exécuter les tests et interpréter leurs résultats (documentation Apple sur l’exécution et l’interprétation des tests). Utilisez ces éléments comme preuves complémentaires : le journal explique la séquence d’exécution, tandis que le paquet fournit des résultats consultables.

Adoptez une règle de nommage ou de métadonnées qui rapproche le paquet de résultats de l’identifiant de tâche et du nœud. Ne vous appuyez pas uniquement sur un nom de fichier générique ou sur le dernier paquet présent dans un répertoire partagé. Si l’archivage est géré par le flux de travail, vérifiez qu’il se produit aussi après un échec de test ; sinon, le scénario le plus important à examiner risque de ne laisser aucune preuve exploitable.

Les journaux de diagnostic du Runner complètent les journaux de tâche. La documentation GitHub les présente dans le cadre du diagnostic des Runners auto-hébergés (consignes de surveillance et de diagnostic des Runners). Contrôlez leur accessibilité sur le nœud et leur association avec la période concernée. Un journal local oublié lors d’un remplacement ou inaccessible à l’équipe ne constitue pas une stratégie de diagnostic.

Un Runner GitHub Actions en ligne mais sans travail

Commencez par comparer les champs d’état et d’occupation du Runner avec les étiquettes, le groupe et les critères de routage du flux de travail. Consultez ensuite les états des exécutions et des tâches pour savoir si le travail attend avant son attribution ou s’il a été dirigé vers un autre nœud. L’état « en ligne » ne prouve ni la compatibilité du Runner ni la bonne configuration du flux de travail.

Les états à surveiller sur une machine de compilation Mac

Associez la disponibilité de l’hôte à l’état de connexion et d’occupation du Runner, puis aux états de tâche, aux étapes, aux résultats de test et aux journaux. Complétez cette chaîne par les mesures de ressources qui expliquent réellement les incidents de votre équipe. Pour la Mac CI observabilité, le critère décisif est le lien entre chaque signal, une tâche identifiée et le nœud qui l’a exécutée.

Relier un échec Xcode à ses preuves

Conservez l’identifiant de l’exécution et de la tâche avec le journal, puis archivez le paquet de résultats de tests associé. Depuis la vue d’une tâche en échec, une personne d’astreinte doit pouvoir ouvrir ces éléments et identifier l’étape fautive sans deviner quel fichier appartient à quel travail. Testez ce parcours avec un échec contrôlé, y compris lorsque l’archivage intervient après l’échec.

Valider la qualité d’une alerte

Simulez un Runner indisponible, une tâche qui échoue ou un résultat absent dans un environnement sûr. Vérifiez qui reçoit l’alerte, si elle désigne le bon nœud et la bonne tâche, puis si les éléments de diagnostic sont accessibles. Fermez le test uniquement lorsque l’équipe peut établir la cause ou l’étape à examiner et conserver une preuve du rétablissement.

Utilisez la liste de contrôle suivante après vos essais. Un contrôle « non » doit désigner un défaut précis et un responsable de correction ; il ne doit pas être masqué par la réussite d’une compilation isolée.

• [ ] L’état de l’hôte et celui du Runner sont contrôlés séparément.
• [ ] Les étiquettes et les règles de routage sont vérifiables.
• [ ] Les exécutions en attente, commencées, réussies, échouées et annulées sont identifiables dans le parcours de diagnostic retenu.
• [ ] Les mesures de ressources peuvent être rapprochées du nœud et de la tâche.
• [ ] Les journaux de tâche, diagnostics du Runner et résultats Xcode sont accessibles à l’équipe autorisée.
• [ ] Une alerte de test conduit à l’exécution concernée et à une action de diagnostic claire.
• [ ] Le rétablissement est vérifié au moyen d’une nouvelle preuve, et non supposé après la disparition de l’alerte.

Prononcez l’admission lorsque les signaux nécessaires sont reliés à une tâche et à un nœud et que l’équipe a démontré sa capacité à diagnostiquer les scénarios retenus. Accordez un délai de correction si un défaut est borné, documenté et ne compromet pas le contrôle des incidents critiques. Reportez l’ouverture à la production si les tâches ne sont pas traçables, si les journaux sont inaccessibles ou si personne ne reçoit les alertes.

La supervision ne remplace ni les sauvegardes, ni la restauration après incident, ni les règles d’approbation des versions. Elle permet de détecter et d’examiner des événements ; elle ne prouve pas qu’un artefact peut être restauré, qu’une signature est conforme ou qu’une publication est autorisée. Gardez ces critères dans leurs propres procédures et reliez-les au flux de travail lorsque cela améliore la traçabilité.

Si votre capacité actuelle repose sur des Mac achetés et administrés sur site, vous devez prévoir l’immobilisation du budget matériel, le remplacement et la maintenance, ainsi que les délais nécessaires pour ajouter un nœud quand la demande augmente. La location d’un Mac distant peut convenir à un essai de CI, à une capacité temporaire ou à un nœud supplémentaire sans achat immédiat. Elle ajoute toutefois une dépendance au réseau et une dépense récurrente ; elle ne répond pas à tous les besoins d’une charge durablement soutenue ou d’un accès à des interfaces physiques.

Avant d’ajouter une capacité, utilisez les résultats de l’essai pour décrire les besoins réels : outils requis, parcours de connexion, accès d’administration attendu et critères de supervision à reproduire. Vous pouvez consulter les tarifs CALMVPS pour comparer une dépense récurrente à la gestion d’un parc acheté, puis examiner l’option de location de Mac à distance si votre équipe doit valider un nœud sans engagement matériel immédiat. Ne retenez cette piste qu’après avoir vérifié que votre réseau, vos exigences de sécurité et vos règles d’exploitation l’autorisent.