Bitbucket Pipelines macOS Runner : norme entreprise 2026

Ce guide s’adresse aux responsables IT qui préparent l’intégration de Bitbucket Pipelines dans une chaîne iOS, aux équipes plateforme qui doivent accepter des Mac auto-hébergés et aux responsables techniques qui évaluent une capacité de compilation fixe ou distante.

Il ne s’agit pas d’un tutoriel d’installation générique. L’objectif est de décider si un nœud peut recevoir une charge de production, dans quelles conditions et avec quel niveau de confiance.

Bitbucket Pipelines macOS Runner exécute les étapes par Bash directement sur l’hôte macOS. La présence « en ligne » confirme la connexion du Runner, pas l’absence de modifications laissées par une tâche précédente. Ce mode d’exécution impose donc une séparation opérationnelle entre les dépôts approuvés, les contributions externes, les tests et la signature de production. La documentation officielle sur les Runners macOS décrit ce fonctionnement côté Atlassian.

Votre décision doit suivre une règle simple :

• si le dépôt est approuvé, le nœud est dédié, le nettoyage est vérifié et les secrets sont isolés, vous pouvez envisager une mise en production limitée ;
• si le script peut modifier l’hôte ou si la preuve de nettoyage manque, vous devez le renvoyer vers un nœud de test ;
• si le nœud de signature partage son environnement avec des contributions externes, vous devez suspendre le déploiement et créer un autre groupe de Runners.

Écriture hors du répertoire de travail

Un script de compilation peut écrire dans le répertoire du dépôt, mais aussi dans des emplacements globaux, les caches d’outils, les données dérivées ou le trousseau de l’utilisateur. Il peut également installer une dépendance, modifier une préférence, créer un service persistant ou laisser un processus en arrière-plan.

Le risque est cumulatif. Une compilation suivante peut utiliser une dépendance qui n’est pas déclarée dans le dépôt. Un test peut lire une variable laissée dans l’environnement. Un processus oublié peut conserver un port ouvert ou un fichier verrouillé. Le résultat semble alors aléatoire, alors que la cause est une mutation de l’hôte.

Avant toute autorisation, faites exécuter un dépôt de contrôle qui tente explicitement de :

• créer un fichier hors de l’espace de travail ;
• installer un outil à portée globale ;
• lancer un processus persistant ;
• modifier un élément du trousseau ;
• remplir un cache utilisé par une autre tâche.

Le test ne doit pas seulement rechercher un résultat de compilation. Il doit produire une liste des modifications avant et après l’exécution, avec le compte utilisé, les chemins concernés et l’action de correction.

Nettoyage du workspace et des données dérivées

Le nettoyage doit couvrir plusieurs catégories, car la suppression du répertoire courant ne suffit pas :

• sources extraites, artefacts temporaires et fichiers de configuration ;
• données dérivées Xcode et archives intermédiaires ;
• caches de dépendances dont le contenu peut influencer une résolution ultérieure ;
• processus enfants, agents et services lancés par le script ;
• certificats, profils, mots de passe et fichiers de clé importés pour la signature.

Distinguez dans votre preuve ce que Bitbucket Pipelines nettoie automatiquement de ce que votre équipe doit gérer. Cette distinction doit apparaître dans le runbook et dans les journaux. Un nettoyage déclaré dans le YAML n’est pas une preuve : vous devez vérifier l’état réel du Mac après une exécution interrompue, échouée et réussie.

Pour une chaîne iOS, répétez le contrôle avec une compilation qui échoue volontairement après l’importation temporaire d’un certificat. Le test est réussi uniquement si le certificat, le profil et les fichiers auxiliaires ne sont plus exploitables lors de la tâche suivante.

Séparation par confiance

Un seul script de nettoyage ne remplace pas une isolation de confiance. Les dépôts internes approuvés, les contributions externes et les tâches de publication n’ont pas le même profil de risque.

Organisez au minimum les rôles suivants :

• un groupe de test pour les dépôts non approuvés et les changements expérimentaux ;
• un groupe de compilation pour les sources internes sans privilège de publication ;
• un groupe de signature et de distribution, accessible uniquement aux pipelines autorisés.

Cette séparation peut correspondre à des Mac distincts ou à des capacités gérées séparément, mais elle doit être observable dans Bitbucket Cloud. Vous devez pouvoir répondre à la question suivante : quel dépôt peut appeler quel nœud, et quels secrets ce nœud peut-il lire ?

Un Repository Runner est rattaché à un dépôt. Un Workspace Runner peut être utilisé dans le périmètre de l’espace de travail concerné. La différence est une différence d’autorisation, pas seulement une commodité administrative. La procédure officielle d’ajout d’un Runner précise les niveaux de rattachement disponibles.

Choisissez un Repository Runner lorsque le nœud contient des secrets spécifiques à un produit, lorsque le dépôt est particulièrement sensible ou lorsque l’équipe responsable doit limiter l’accès au strict nécessaire.

Choisissez un Workspace Runner uniquement si plusieurs dépôts doivent réellement partager une capacité et si vous avez documenté :

• les dépôts autorisés ;
• les étiquettes utilisables ;
• le niveau de secret associé à chaque nœud ;
• la procédure de retrait d’un dépôt ;
• la personne qui approuve une modification de routage.

Les étiquettes doivent exprimer une capacité et un niveau de confiance. Une nomenclature telle que macos, ios-build, apple-silicon et signing-prod est plus exploitable qu’une étiquette ambiguë comme fast. Dans le fichier bitbucket-pipelines.yml, le bloc minimal doit rendre visible le chemin vers la capacité attendue :

runs-on:
  - macos
  - self.hosted
  - ios-build
  - apple-silicon

Adaptez les étiquettes à celles réellement enregistrées dans votre espace. Le guide Atlassian sur le routage YAML explique la correspondance entre les étiquettes du pipeline et celles du Runner.

L’acceptation exige trois essais négatifs. Appelez une étiquette erronée, envoyez une tâche alors que le nœud cible est occupé, puis utilisez une combinaison sans correspondance. La tâche doit rester en attente ou échouer de manière explicite. Elle ne doit pas être exécutée sur un Runner possédant davantage de privilèges.

Pour comprendre la concurrence réelle, observez la file d’attente pendant ces essais et conservez les journaux. La documentation sur la concurrence et la file des étapes fournit les éléments à contrôler côté Bitbucket.

Un Mac qui compile aujourd’hui n’est pas nécessairement un Mac reproductible demain. Le registre d’acceptation doit identifier le système macOS, Xcode, les SDK, les gestionnaires de dépendances, les outils auxiliaires et le compte d’exécution. Les versions exactes doivent être relevées le jour du déploiement, puis comparées aux exigences de votre projet et à la documentation officielle.

Ne déduisez pas une capacité à partir du seul processeur Apple Silicon. Cette architecture peut convenir à la compilation iOS, à des tâches audio ou vidéo et à certains flux de design, mais la compatibilité dépend aussi de Xcode, des dépendances et des scripts du projet. La référence Apple des outils de ligne de commande Xcode doit accompagner votre contrôle des outils installés.

Exécutez le même commit au moins dans deux états distincts :

• après une préparation contrôlée du nœud ;
• après suppression des caches et données générées autorisées.

Comparez les journaux de résolution des dépendances, les erreurs, les empreintes des artefacts et les archives produites. Si le résultat dépend d’un cache non documenté, classez le nœud comme non prêt pour une publication reproductible.

Les paramètres Linux ou d’un autre environnement de pipeline ne doivent pas être copiés automatiquement. Vérifiez chaque commande, chaque chemin, chaque outil et chaque hypothèse de shell sur macOS. Le fait qu’une étape soit valide dans Bitbucket Pipelines pour une autre famille de nœuds ne prouve pas qu’elle soit supportée par votre Runner macOS.

Séparez quatre familles de données :

• le jeton d’enregistrement du Runner ;
• les identifiants d’accès au code et aux dépendances ;
• les certificats et profils Apple ;
• les autorisations de distribution ou de publication.

Aucune de ces familles ne doit être inscrite en clair dans le dépôt, dans un script partagé ou dans une image d’environnement. Les règles Atlassian sur les variables et les secrets doivent être rapprochées de votre propre matrice d’accès.

La signature mérite une validation indépendante. Importez un certificat temporaire, exécutez l’étape prévue, produisez l’artefact, puis supprimez le matériel cryptographique. Contrôlez ensuite le trousseau, les profils, les fichiers temporaires et les journaux. La note technique Apple TN3161 sur les certificats de signature aide à distinguer le certificat, la clé privée et les éléments de chaîne.

Testez également les frontières entre nœuds. Une tâche affectée au groupe de test ne doit pas pouvoir lire le trousseau du groupe de signature. Un cache partagé ne doit pas transporter un artefact de publication vers une compilation ordinaire. Un dépôt ne doit pas obtenir indirectement une variable configurée pour un autre produit.

Pour une publication macOS ou un artefact signé destiné à la distribution, utilisez la procédure Apple correspondant au type de code concerné. La documentation Apple sur la création de code signé pour la distribution rappelle que la signature fait partie de la chaîne de distribution et ne doit pas être traitée comme une simple étape de compilation.

Votre dossier d’audit doit contenir la date d’importation, le propriétaire de l’autorisation, le résultat de l’utilisation, la suppression, la rotation et la révocation d’urgence. Une variable protégée sans preuve de révocation reste un risque non mesuré.

La reprise ne se résume pas à constater que l’icône repasse en ligne. Exécutez séparément les scénarios suivants :

• arrêt du processus Runner ;
• redémarrage du Mac ;
• perte temporaire du réseau ;
• annulation d’une tâche pendant la compilation ;
• retour d’un nœud après une interruption.

Après chaque événement, vérifiez l’état du Runner, la présence de processus résiduels, l’état du workspace et la capacité à recevoir une nouvelle tâche. Une reconnexion réussie avec un workspace contaminé est un échec d’acceptation.

Documentez aussi le comportement d’une tâche placée en file. Un nœud indisponible ne doit pas provoquer une attribution silencieuse à une capacité plus privilégiée. Les informations de file et de concurrence doivent être conservées avec les journaux de l’incident, conformément aux indications Atlassian sur l’inspection des étapes en attente.

La capacité se calcule à partir de vos tâches réelles, pas du nombre de développeurs ni d’une promesse matérielle. Relevez la durée des compilations, la profondeur maximale de la file, la capacité effective par nœud et la marge nécessaire lorsqu’un nœud est indisponible. Séparez les tâches de test, d’archivage et de signature dans vos observations.

Vous pouvez alors appliquer cette décision :

• si la file reste maîtrisée pendant vos pics observés et qu’un nœud peut être retiré sans bloquer une publication, choisissez une mise en production limitée ;
• si les tâches de signature attendent derrière des tests ordinaires, créez un pool réservé avant d’augmenter le trafic ;
• si la capacité n’est acceptable qu’avec un nœud toujours disponible, ajoutez une redondance ou réduisez le périmètre avant le lancement ;
• si les résultats varient après nettoyage, revenez à l’analyse de l’environnement plutôt qu’à l’achat de puissance supplémentaire ;
• si la reprise exige une connexion manuelle, classez le service en capacité assistée et non en infrastructure sans surveillance.

Pour les équipes qui évaluent une capacité distante, consultez d’abord la présentation française de CALMVPS, puis confrontez la durée retenue à votre propre charge. Une offre de location ne remplace pas les tests d’acceptation : elle vous permet surtout de tester une capacité Mac sans immobiliser immédiatement du matériel dans vos locaux.

Rassemblez un dossier par pool de Runners. Il doit relier chaque exigence à une action, une sortie observable, un seuil d’acceptation et une décision de traitement en cas d’échec.

Votre liste de contrôle peut être utilisée ainsi :

• [ ] Le mode d’exécution sur l’hôte est documenté pour l’équipe plateforme.
• [ ] Les écritures hors workspace ont été détectées et traitées.
• [ ] Les données dérivées, caches contrôlés, processus et fichiers temporaires ont été vérifiés.
• [ ] Les dépôts externes ne partagent pas un nœud de signature.
• [ ] Le périmètre Repository ou Workspace est justifié.
• [ ] Les étiquettes de test, compilation et publication ont été validées par des essais positifs et négatifs.
• [ ] Le même commit a été rejoué après nettoyage.
• [ ] Les certificats et profils sont importés, utilisés, supprimés et révocables.
• [ ] Les arrêts, redémarrages, coupures réseau et annulations ont été enregistrés.
• [ ] La file d’attente et la capacité effective ont été mesurées sur des tâches représentatives.
• [ ] Un propriétaire est désigné pour chaque alerte et chaque rotation de secret.

La conclusion doit appartenir à une seule des quatre catégories suivantes : pilote isolé, production limitée, mise en production complète ou retour en correction. Ne mélangez pas ces statuts. Une compilation iOS réussie ne compense pas un échec de séparation des secrets. Une reprise rapide ne compense pas une route YAML qui accepte un nœud de signature pour un dépôt non autorisé.

Pour comparer la capacité fixe et la capacité distante sans confondre prix facial et coût réel, consultez les formules de location Mac de CALMVPS. Intégrez à votre analyse le temps d’administration, la maintenance du poste, la gestion des pannes, la redondance et le retrait des machines. Le choix est pertinent seulement si le niveau de contrôle et les preuves exigées restent compatibles avec votre politique de sécurité.

Les réponses ci-dessous complètent la grille d’acceptation. Elles ne remplacent pas la vérification de la documentation Atlassian applicable au moment de l’enregistrement.

Un Bitbucket macOS Runner peut-il recevoir une tâche de publication iOS ? Oui, si son environnement Xcode est maîtrisé et si les certificats, profils et autorisations sont réservés à un pool de confiance. Il faut tester séparément les dépôts internes et les contributions externes, puis prouver la suppression du matériel de signature après chaque exécution.

Le périmètre Workspace est-il adapté à plusieurs dépôts ? Il peut l’être pour une capacité de compilation commune, mais il augmente le rayon d’autorisation. Vous devez donc inventorier les dépôts appelants, réserver les étiquettes sensibles et empêcher qu’un dépôt ordinaire atteigne un nœud qui contient des clés de distribution ou des variables de publication.

Que faut-il conserver après un nettoyage macOS ? Conservez le journal de l’exécution, la liste des processus contrôlés, le résultat de l’inspection du trousseau, les chemins supprimés et la preuve de révocation ou de rotation lorsque des secrets ont été utilisés. Le but est de démontrer l’état final du poste, pas seulement l’intention du script.

Un Runner hors ligne reprend-il automatiquement les tâches ? Ne fondez pas votre décision sur cette hypothèse. Testez l’arrêt de l’agent, le redémarrage du Mac, l’interruption réseau et le retour dans la file. Si le nœud revient sans intervention, vérifiez encore que son workspace est propre et qu’il ne récupère pas une tâche avec des privilèges inadaptés.

Comment valider un fichier bitbucket-pipelines.yml pour Apple Silicon ? Vérifiez les étiquettes réellement enregistrées, la compatibilité des commandes avec macOS et l’architecture attendue par vos dépendances. Une tâche de contrôle doit confirmer le routage vers le bon pool avant d’autoriser une archive ou une signature de production.

Si votre environnement actuel repose sur un Mac partagé, vous subissez généralement trois défauts : les tâches se contaminent par les caches ou processus résiduels, les secrets sont plus difficiles à cloisonner et la capacité devient imprévisible lorsqu’un poste est redémarré ou occupé. L’achat de machines locales ajoute en outre la maintenance, le remplacement matériel et une capacité souvent surdimensionnée hors des périodes de pointe.

La location d’un Mac distant auprès de CALMVPS peut offrir une capacité dédiée et accessible à distance pour un pilote, une montée en charge temporaire ou un pool de compilation séparé. Elle ne convient pas à tous les cas : une charge durable et parfaitement prévisible peut justifier l’achat d’un parc, tandis qu’un besoin d’accès physique spécifique impose un poste local. Dans les autres situations, commencez par exécuter cette grille sur une ligne non productive, puis examinez les options de commande d’un Mac distant CALMVPS seulement lorsque l’isolation, la suppression des signatures et la reprise sans intervention sont démontrables.