Comment configurer le cache distant Bazel pour iOS ? Guide Mac distant 2026

Le cache ne permet pas de rendre fiable une compilation dont les conditions ne sont pas encore maîtrisées. Avant de le configurer, exécutez sur une machine de référence les cibles Bazel réellement utilisées par le projet, notamment celles qui construisent et testent l’application. Conservez les commandes, la sortie du terminal, les erreurs éventuelles et les éléments permettant d’identifier l’artefact produit.

La référence ne se résume pas à une version de Bazel. Notez également les règles Apple et Swift déclarées par le dépôt, la version de Xcode sélectionnée, le SDK employé, les options transmises à Bazel, la cible iOS et les variables d’environnement pertinentes. Pour les dépendances, préférez les fichiers de verrouillage et la configuration déjà versionnée à des versions recopiées manuellement dans un document séparé.

Un relevé utile doit permettre à un collègue de rejouer le même build et de comparer son résultat, plutôt que de reconstruire de mémoire les étapes exécutées. Enregistrez notamment :

• le commit ou l’état exact du dépôt ;
• les commandes de build et de test, avec leurs options ;
• les versions de Bazel, de rules_apple et de rules_swift définies par le projet ;
• le chemin du Xcode actif et les informations du SDK ;
• la destination, la configuration et les paramètres de compilation ;
• les journaux, les messages d’échec et les éléments de contrôle de l’artefact.

La documentation du dépôt officiel rules_apple sert à contrôler les règles Apple effectivement utilisées ; elle ne remplace pas les fichiers de dépendances du projet. Il faut confronter les indications générales aux versions verrouillées et à la configuration en place, sans déduire une compatibilité précise d’une page décrivant une autre révision.

Une compilation locale réussie devient la référence de comparaison, pas une preuve que le cache est opérationnel. Si le résultat change entre deux exécutions faites dans des conditions supposées identiques, examinez d’abord les options, les dépendances et l’environnement. Introduire simultanément un nouveau Mac et un cache distant ajouterait des variables et rendrait le diagnostic moins net.

Sur le Mac distant, identifiez les outils réellement sélectionnés par le système, puis comparez-les au relevé de référence. Le fait que Xcode soit installé ne prouve pas que ses outils de ligne de commande ou le SDK attendu sont ceux qu’utilise la compilation.

Les commandes Apple permettent de consulter le chemin du développeur actif et les informations disponibles sur Xcode ou les SDK. La référence Apple des outils de ligne de commande Xcode documente ces commandes. Si la sélection des outils paraît incorrecte, vérifiez la procédure Apple pour installer les outils de ligne de commande, puis consignez le résultat réellement observé.

Sur les deux machines, comparez le dépôt, les fichiers de verrouillage, la configuration Bazel, la cible, les options, les variables d’environnement et le Xcode actif. Faites ensuite exécuter au Mac distant les mêmes commandes que celles de la référence, sans modifier le projet pour contourner une erreur qui doit encore être comprise. Si la compilation échoue, lisez le journal, isolez l’action concernée et confrontez son besoin à la documentation Apple et aux règles employées.

À vérifier avant de poursuivre : un build réussi sur le poste local et un build échoué sur le Mac distant indiquent d’abord un écart d’environnement ou de configuration à caractériser. Ils ne constituent pas une preuve de défaillance du cache, qui n’est pas encore la variable à tester.

Pour consigner les observations de manière exploitable, distinguez trois éléments : ce qui est identique, ce qui diffère et ce qui reste à vérifier. Par exemple, « Xcode installé » est une observation insuffisante ; le chemin des outils sélectionnés et le SDK choisi par la commande utilisée sont plus utiles. La comparaison doit porter sur les entrées effectives du build, pas seulement sur la description théorique de la machine.

Lorsque le Mac distant reproduit le build de référence, choisissez le point de configuration du cache et le mécanisme d’authentification adaptés à l’infrastructure retenue. La documentation Bazel décrit les possibilités de mise en cache à distance et les paramètres associés. Vérifiez la syntaxe et le comportement au regard de la version de Bazel utilisée par le projet : une option valide dans une documentation de référence n’est pas automatiquement valide pour toute installation.

Évitez d’inscrire un secret dans un fichier partagé ou dans une commande susceptible d’être conservée dans les journaux. La configuration versionnée peut fournir les paramètres non sensibles ; l’identité de l’agent et l’accès au secret doivent être traités selon les mécanismes de contrôle de la CI ou de l’environnement d’exécution. Le test est incomplet si le build fonctionne seulement parce qu’un poste utilise un jeton personnel non documenté.

Séparez explicitement les droits de lecture et d’écriture. Les postes de développement peuvent avoir besoin de consommer des résultats approuvés sans pour autant publier tout résultat dans le cache commun. Les tâches de CI autorisées à écrire doivent disposer d’une identité contrôlée, limitée à l’usage prévu. Conservez la revue de configuration et les règles d’accès comme éléments de validation, au lieu de vous fier à la seule présence d’une option dans un fichier.

Enfin, déterminez quelles actions ne doivent pas partager ces résultats dans le contexte du projet. Une étape dépendant d’un secret, d’un état local ou d’une décision de livraison doit faire l’objet d’un examen spécifique avant son inclusion dans le cache. Les conditions concrètes dépendent de la configuration Bazel et du backend ; si elles ne sont pas établies, n’élargissez pas les droits d’écriture par commodité.

Une fois l’accès configuré, vérifiez la réutilisation intermachines au lieu de conclure à partir du seul succès d’une compilation. Faites construire une même cible à partir d’un état de dépôt connu sur le premier Mac, avec la configuration destinée à publier les résultats. Puis, sur le second Mac, rejouez la même cible avec les mêmes entrées et la configuration destinée à lire le cache.

Comparez les journaux des deux exécutions et relevez les indices explicites de lecture ou de résultat récupéré depuis le cache. La sortie exacte dépend de la version, de la commande et du backend ; il est donc préférable de conserver les journaux bruts et de les interpréter avec la documentation de Bazel plutôt que d’attendre un libellé unique. Le guide Bazel consacré au diagnostic des problèmes de cache distant aide à distinguer une entrée absente, un accès refusé et une absence de réutilisation.

Pour rendre l’essai comparable, consignez le commit, les options, les variables pertinentes, l’identité utilisée et le résultat observé sur chaque machine. Si la seconde compilation passe mais ne montre aucun accès distant, le résultat prouve seulement que cette machine a construit la cible ; il ne prouve pas que le cache a servi un artefact. Inversement, un accès au cache ne dispense pas de vérifier que le build et les tests donnent un résultat acceptable.

Décider quoi corriger avant de relancer

• Si le Mac lecteur n’atteint pas le point de terminaison, alors vérifiez le réseau, l’adresse et la résolution des accès avant de modifier les règles du projet.
• Si la connexion fonctionne mais que le service refuse la requête, alors contrôlez l’identité, les droits de lecture et la transmission du secret.
• Si l’accès réussit mais que le résultat attendu n’est pas réutilisé, alors comparez le commit, les options, les variables, les outils actifs et les entrées qui déterminent l’action.
• Si le second Mac récupère un résultat identifiable et que le build passe, alors répétez l’essai après avoir contrôlé les journaux et l’artefact ; étendez l’usage seulement si la preuve demeure cohérente.

Point de méthode : modifiez un facteur à la fois pendant le diagnostic. Changer simultanément la configuration, le Xcode sélectionné et les autorisations du cache peut faire disparaître l’erreur sans révéler sa cause, et complique toute reproduction ultérieure.

L’absence de résultat partagé n’est pas toujours un incident du service. Les machines peuvent avoir des entrées de compilation différentes parce que leur environnement effectif, leurs paramètres ou leurs dépendances ne correspondent pas. Au lieu d’assouplir les vérifications ou d’autoriser davantage d’écritures, trouvez l’écart mesurable, corrigez-le puis répétez le même essai.

Le cache distant Bazel et l’exécution distante répondent à des besoins distincts. Le premier permet de réutiliser des résultats de build lorsqu’ils sont disponibles et valides pour les entrées considérées. La seconde vise à envoyer des actions de construction vers des exécutants distants. La présentation Bazel de l’exécution distante décrit ce mécanisme séparément du cache : activer ou observer l’un ne prouve pas que l’autre est actif.

Cette différence est particulièrement importante pour un projet Apple. Le Mac doit disposer d’un environnement capable d’utiliser les outils Apple nécessaires aux actions concernées ; un cache ne fournit ni Xcode ni le SDK et n’efface pas les contraintes des règles de construction. Consultez les indications de rules_apple et la documentation d’Apple pour vérifier le besoin réel de chaque action, plutôt que de supposer que toutes les étapes iOS se déplacent de la même manière vers un exécutant distant.

La construction du paquet et sa signature exigent, elles aussi, des preuves séparées. Une action récupérée depuis le cache n’atteste ni que le bon profil a été utilisé, ni que le certificat est accessible, ni que l’application produite est distribuable. Définissez une étape de livraison contrôlée sur un Mac autorisé, avec les accès au trousseau et aux éléments de signature gérés selon les règles de l’équipe. La documentation Apple sur la création de code signé pour la distribution décrit le processus de signature et de distribution ; vérifiez les procédures applicables au type d’application et au flux iOS réellement utilisés.

En pratique, consignez séparément les preuves suivantes : indication de lecture du cache, preuve d’exécution distante si cette fonction est configurée, résultat du build, résultats des tests, inspection du paquet et validation de signature. Ne présentez pas une compilation verte comme une preuve de publication réussie. Si l’équipe ne met en place que le cache, décrivez le résultat comme une réutilisation de build, sans l’appeler exécution distante.

La CI doit employer une configuration Bazel comparable à celle vérifiée sur les Mac de développement. Comparez les fichiers de configuration chargés, les options effectives et l’identité du travail automatisé. Vérifiez que cette identité lit le cache comme prévu et que seules les tâches désignées peuvent y publier des résultats. Une différence discrète dans les options ou les variables peut empêcher une comparaison valide, même si les commandes semblent similaires.

Avant d’élargir l’utilisation, rejouez le flux complet sur le projet réel : compilation, tests, création du paquet et vérification de la signature selon le processus de livraison. Examinez également le comportement lorsque le cache est inaccessible : les journaux doivent aider à identifier l’incident, et l’équipe doit savoir si la tâche échoue, se poursuit sans cache ou suit une autre procédure approuvée. Ne modifiez pas silencieusement les règles d’accès pour masquer un défaut.

Liste de validation avant la mise en service

• [ ] Le build et les tests de référence sont rejouables sur le poste local.
• [ ] Le Mac distant sélectionne le Xcode et le SDK attendus par le projet.
• [ ] Les fichiers verrouillés et les paramètres Bazel ont été comparés.
• [ ] L’adresse du cache et son authentification ont été examinées.
• [ ] Les droits de lecture et de publication sont associés à des identités explicites.
• [ ] Les secrets ne sont pas exposés dans les fichiers partagés ou les journaux.
• [ ] Une lecture effective du cache a été observée depuis une autre machine.
• [ ] Les tests, le paquet et la signature font l’objet de contrôles distincts.
• [ ] La procédure CI a un comportement documenté si le cache est indisponible.

La décision de poursuivre doit s’appuyer sur ces preuves, et non sur une amélioration de durée supposée. Si les résultats de construction sont cohérents, que les accès sont maîtrisés et que les journaux établissent la réutilisation, commencez par un périmètre contrôlé. Si les machines ne partagent pas les résultats de façon explicable, corrigez les écarts ou revenez à un build sans cache le temps de rétablir une référence fiable. Sans mesure menée sur le projet et l’environnement concernés, ne promettez pas de gain de performance.

Comment ajouter un cache distant à un projet iOS géré avec Bazel ?

Stabilisez d’abord la compilation sur le Mac de référence, puis configurez l’adresse du cache dans l’entrée Bazel adaptée au projet et à la version utilisée. Définissez séparément l’identité autorisée à lire et celle autorisée à publier. Enfin, faites écrire un résultat par une machine, puis vérifiez qu’une autre le récupère réellement dans ses journaux.

Le cache distant Bazel exécute-t-il aussi les compilations sur le serveur ?

Non. Le cache distant conserve et restitue des résultats de compilation admissibles ; l’exécution distante distribue des actions de construction à des machines distantes. Les deux mécanismes ont des configurations et des preuves de validation distinctes. Un succès du cache ne démontre donc pas que les actions ont été exécutées à distance, ni que le projet peut se passer d’un environnement Apple.

Pourquoi le cache Bazel fonctionne-t-il sur un Mac et pas sur un autre ?

Comparez d’abord le commit, les options de construction, les variables d’environnement, les versions et chemins actifs de Xcode, les SDK sélectionnés, puis l’identité et la connectivité vers le cache. Une compilation réussie ne suffit pas à prouver un accès au cache. Répétez la même cible avec des journaux comparables et traitez chaque différence avant d’attribuer l’écart à Bazel.

Où effectuer la signature et la génération de l’application iOS ?

Traitez la signature comme une étape de livraison contrôlée, séparée de la preuve de réutilisation du cache. Le lieu d’exécution dépend des règles du projet, des certificats, des profils et de la gestion du trousseau. Vérifiez le résultat signé et le paquet final sur un Mac autorisé ; ne déduisez jamais leur validité d’un cache atteint ou d’une action exécutée à distance.

Un runner Linux ne fournit pas à lui seul l’environnement Xcode attendu par un build iOS ; un Mac partagé par l’équipe peut rendre les accès, les dépendances locales et la disponibilité difficiles à maîtriser ; acheter et maintenir une machine dédiée immobilise du matériel, même si le besoin est limité à une phase de test. Pour une équipe qui doit conserver un environnement Apple accessible pendant ses validations Bazel, louer un Mac via NUKCLOUD peut être une option plus souple que l’achat d’une machine dédiée, à condition de vérifier au préalable les modalités d’accès, la configuration réellement proposée et les exigences de sécurité du projet.

Cette option ne convient pas à tous les usages : un poste physique reste préférable lorsqu’un périphérique local précis est indispensable, et un nœud acheté peut être plus cohérent pour une charge lourde permanente déjà bien dimensionnée. Si un Mac hébergé répond au besoin d’exécution continue, consultez les informations de NUKCLOUD sur l’accès à un Mac distant et sa documentation d’assistance, puis validez votre chaîne Xcode et vos contrôles de signature avant d’y déplacer les builds de production.