Les équipes de plate-forme exécutant des exécuteurs macOS auto-hébergés voient le même mode d'échec : des tentatives innocentes cachent de vrais bugs de produits, brûlent des heures Apple Silicon et entraînent les développeurs à se méfier de CI. Ce playbook définit comment classer les flocons, quand réexécuter automatiquement ou bloquer les fusions et comment implémenter une quarantaine basée sur des séquences sur des machines Mac mini M4 dédiées. Avec deux tables de décision et un déploiement en six étapes que vous pouvez copier dans GitHub Actions ou n'importe quel orchestrateur d'exécution.
Si vous répartissez déjà le travail de l'interface utilisateur entre les machines, associez cette stratégie àPartage de test de l'interface utilisateur iOS sur Mac mini M4donc l'inclinaison des fragments ne se fait pas passer pour une desquamation du test. Pour les lignes de base d'installation des canaux d'alimentation, commencez à partir deActions GitHub auto-hébergées sur le cloud Macet gardez les versions Xcode identiques dans toute la flotte.
Pourquoi des tentatives illimitées Poison Trust dans une flotte de build Mac
macOS CI est dynamique, contrairement aux conteneurs Linux : les éléments de trousseau, les caches de simulateur, les verrouillages d'écran et les démons de notaire Apple introduisent tous des modes de défaillance qui semblent aléatoires jusqu'à ce que vous les mesuriez. Sans budget écrit pour les nouvelles tentatives, les ingénieurs d'astreinte interprètent chaque vert après rouge comme « résolu tout seul », ce qui augmente silencieusement le risque de fusion.
- Cécité métrique :Les équipes qui suivent uniquement les réussites/échecs par flux de travail ne peuvent pas savoir si un test a échoué.three different runners or the same overheating host three times.
- Freinage économique :Une seule suite d'interface utilisateur irrégulière qui réessaye deux fois par demande d'extraction peut consommer20–35%de minutes d'exécution hebdomadaires sur Mac, même lorsque le code produit est stable.
- Faux apprentissage :Les développeurs commencent à réexécuter les tâches localement « jusqu'à ce qu'elles soient vertes », en contournant le signal exact que votre porte de fusion devrait protéger.
Empreintes digitales de défaillance : infrastructure, test ou produit ?
Avant de modifier les quotas, marquez les échecs avec une empreinte digitale afin que les tableaux de bord distinguent le signal du bruit. Le tableau ci-dessous est un démarreur de conversation : adaptez la colonne « première action » à vos règles de conformité.
| Empreinte digitale | Conducteur probable | Première action |
|---|---|---|
| Même nom d'hôte du coureur, tests variés | Instabilité du disque, du thermique ou du hub USB | Drainer les emplois ; inspecter SMART et l'espace libre (<15%gratuit déclenche un nettoyage immédiat) |
| Même test, n'importe quel coureur | Le test suppose une horloge murale, une animation ou des paramètres régionaux | Billet de quarantaine ouvert ; tentatives de cap à1 until fixed |
| Spike après le choc de Xcode | Régression de chaîne d'outils ou de simulateur | Épingler le SDK ; exécuter Canary Suite sur un Mac doré avant le déploiement de la flotte |
| Uniquement sur pull_request depuis Forks | Disponibilité secrète ou différences sandbox | Diviser les flux de travail ; ne réutilisez jamais les étiquettes de signature de production sur les travaux à la fourche |
Réessayer le budget et les seuils de quarantaine par maturité de l'équipe
Les équipes matures traitent les tentatives comme un prêt avec intérêts. La matrice ci-dessous mappe trois préréglages de politique aux boutons opérationnels ; choisissez un profil par niveau de référentiel.
| Bouton de politique | Démarreur | Équilibré | Entreprise |
|---|---|---|---|
| Nouvelles tentatives automatiques par tâche | 2 | 1(erreurs infrarouges uniquement) | 0–1avec liste blanche d'erreurs de saisie |
| Strie de flocons en quarantaine | Rapport nocturne | 3 fails in 24 h | 2 fails on main |
| Règle de fusion pour les tests mis en quarantaine | Insigne d'avertissement | Benne optionnelle avec approbation du propriétaire | Blocage dur sauf exception VPAT |
| Rétention de télémétrie des coureurs | 7 days | 30 days | 90jours + export SIEM |
Note d'audit :Lorsque la quarantaine ignore un test, stockez le SHA de validation, l'acteur et l'ID du ticket dans le journal du flux de travail. Les régulateurs et les clients payants demandent de plus en plus la preuve que les chèques ignorés étaient conscients et non des constructions vertes accidentelles.
Six étapes pour déployer la quarantaine basée sur les séquences sur les Cloud Mac Runners
Ces étapes supposent que vous pouvez vous connecter en SSH aux hôtes à des fins de maintenance. L'hygiène de la connexion et la configuration du compte sont documentées dans notrehelp center.
- Émettez des faits structurés sur les coureurs :Ajouter
RUNNER_NAME, la version du système d'exploitation, la version Xcode et les Go de disque libre dans chaque résumé de tâche. - Classer les tentatives :Distinguer
infra_retry(timeouts, démarrage du simulateur) à partir detest_retry(échecs d’assertion). - Suivez les séquences par test :Conserver les comptes dans une petite base de données ou un magasin d'objets ; réinitialiser les séquences seulement après10 consecutive greens on
main. - Portes de fusion de fils :Bloquez lorsque la séquence dépasse votre seuil de niveau, sauf si une étiquette de responsable est présente.
- Faites pivoter les mauvais acteurs :Si un nom d'hôte apparaît dans40% of infra retries in a week, pull it from service and reimage.
- Révision hebdomadaire :Limiter l'heure de la réunion à25 minutes with a dashboard that lists top flake contributors and recovered tests.
Métriques à exporter avant votre prochain examen d'incident
Les dirigeants demandent des pourcentages verts ; les ingénieurs en fiabilité ont besoin de distributions. Planifiez une tâche hebdomadaire qui écrit les agrégats suivants dans votre entrepôt afin que les décisions de quarantaine restent basées sur les données plutôt que politiques. La corrélation de ces métriques avec le nom d'hôte du coureur et l'ID de build Xcode expose généralement un seul nœud défectueux bien avant que les développeurs n'ouvrent les tickets.
- Durée ajustée après nouvelle tentative :Heure murale incluant toutes les tentatives ; comparer avec la durée de la première tentative pour quantifier la taxe de nouvelle tentative.
- Indice d'intermittence :Nombre de tâches qui sont passées du rouge au vert sans nouvelle validation ; visez à conduire cela ci-dessous5%de tâches macOS par sprint.
- Âge du retard de quarantaine :Nombre de jours écoulés depuis la dernière exécution réussie de chaque test ignoré sur la branche principale ; faire remonter tout ce qui est plus ancien que14 days.
- Démarrage du simulateur p95 :Effectuez un suivi distinct des organismes de test : l'augmentation des temps de démarrage prédit souvent une défaillance du stockage avant le déclenchement des alertes SMART.
- Échecs de portée secrète :Suivez les erreurs d'authentification séparément afin de ne pas gaspiller de tentatives avec des erreurs mal configurées.
APP_STORE_CONNECTkeys.
Lorsque les métriques se trouvent à côté des événements de déploiement, vous pouvez répondre aux questions d'audit en quelques minutes : quel Mac a touché un artefact donné, quelles versions de Xcode étaient actives lors d'un pic et si les nouvelles tentatives ont masqué une régression surmain. Ce récit est aussi important que le taux de réussite brut lorsque vos contrats clients incluent des clauses de disponibilité pour les plates-formes de développement internes.
FAQ
Les demandes d'extraction forcées devraient-elles utiliser les mêmes étiquettes Mac que les versions de version ?
Ne partagez jamais d’étiquettes capables de signer avec des chemins de code non fiables. Traitez les forks comme des locataires non fiables : des pools d'exécution distincts, des étendues de secrets distinctes et des budgets de nouvelle tentative plus restreints afin que les flux de travail malveillants ne puissent pas sonder votre infrastructure.
Comment la géographie interagit-elle avec les taux de flocons ?
Les tests dépendants du réseau (notifications push, cas extrêmes CDN) doivent être exécutés dans la région la plus proche de vos utilisateurs. NodeMac propose des nœuds à Hong Kong, au Japon, en Corée, à Singapour et aux États-Unis : placez chaque mois des tâches Canary dans chaque région pour détecter la dérive DNS ou TLS avant qu'elle n'atteigne chaque développeur.
Lorsque vous êtes prêt à ajouter des coureurs isolés pour les suites mises en quarantaine, comparezTarifs NodeMaccontre le coût de brûler les heures de révision de votre équipe sur de faux rouges.
Le matériel Mac mini M4 correspond à ce playbook car Apple Silicon combine des performances rapides en monothread pour l'orchestration Xcode avec une alimentation inactive efficace lorsque les coureurs sont assis entre des rafales de demandes d'extraction. Fournitures NodeMacMac mini physique dédiémachines (et non des VM sursouscrites) avec SSH et VNC afin que vous puissiez déboguer les simulateurs bloqués de la même manière que vous le feriez sur un ordinateur de bureau. La location à Hong Kong, Tokyo, Séoul, Singapour ou aux États-Unis vous permet de colocaliser une reproduction irrégulière de l'interface utilisateur avec les conditions réseau que votre application voit réellement, tout en évitant les dépenses d'investissement initiales pour un deuxième placard de Mac « quarantaine uniquement ».