DevOps / CI·CD 20 avril 2026

2026-04-20 CI déterministe Ruby Bundler et CocoaPods sur Mac cloud Apple Silicon loué

Équipe ingénierie MacXCode 20 avril 2026 ~15 min de lecture

Les équipes qui louent des builders Mac mini M4 ou Mac Studio en SSH pour l’iOS CI hébergent encore beaucoup de bases CocoaPods. Le mode d’échec n’est jamais « Pods est mauvais », mais des toolchains Ruby non déterministes : un job utilise le pod système, un autre une mise à jour Homebrew du mardi, un troisième ce que gem install cocoapods a laissé dans ~/.gem. Ce runbook du 2026-04-20 normalise CocoaPods géré par Bundler sur des hôtes Apple Silicon loués dans HK / JP / KR / SG / US, aligne les caches sur des espaces de travail par job et garde le NVMe prévisible sur machines multi-locataires. Lisez aussi SwiftPM vs CocoaPods, CLT vs Xcode complet et jobs xcodebuild parallèles pour synchroniser résolution des dépendances et compilation.

Pourquoi Bundler reste indispensable sur builders sans tête

CocoaPods est un programme Ruby. L’exécutable pod n’est stable que via l’ensemble de gems derrière lui. Bundler fige cet ensemble avec Gemfile.lock, ce que vous voulez quand douze équipes produit partagent une flotte Mac cloud. Sans Bundler, « vert sur ma branche » signifie souvent « le dernier connecté a mis à jour CocoaPods globalement ».

  • Reproductibilité — même Gemfile.lock → même comportement du résolveur entre régions.
  • Auditabilité — la sécurité peut comparer les versions de gems entre releases.
  • Isolation — bundle install --path vendor/bundle garde les gems dans l’espace de travail, pas dans des homes partagés.

Matrice toolchain Ruby (3.1 vs 3.2 vs 3.3)

Les images macOS Apple Silicon embarquent souvent un Ruby système récent ; certaines équipes ajoutent rbenv ou asdf. Choisissez une politique par flotte et encodez-la dans votre dépôt d’infra. Documentez le ruby -v exact à côté de xcodebuild -version dans les métadonnées de build.

Approche Avantages Risques
Ruby système + Bundler Démarrage rapide sur nouveaux hôtes SSH Les mises à jour OS peuvent faire monter Ruby ; figer via plist ou env CI
rbenv par utilisateur Niveaux de patch exacts Les jobs launchd doivent sourcer explicitement les shims rbenv
asdf avec .tool-versions Un fichier pour Ruby, Node, etc. Premier install plus long

Discipline Gemfile et fichier de verrouillage

Validez Gemfile et Gemfile.lock. Épinglez cocoapods sur un mineur éprouvé et listez les plugins (ex. cocoapods-acknowledgements) explicitement — n’attendez pas « ce que résout le dernier plugin ». En CI, préférez :

bundle config set --local deployment 'true' bundle config set --local path 'vendor/bundle' bundle install --jobs 4 --retry 3

Astuce : lancez bundle check avant pod install pour échouer vite si quelqu’un a oublié de mettre à jour Gemfile.lock après avoir modifié le Gemfile.

bundle exec pod install (et quand ajouter --deployment)

Appelez toujours bundle exec pod install (ou bundle exec pod install --deployment pour forcer strictement le lockfile). N’appelez pas le pod nu en pipelines de production, sauf si vous aimez le non-déterminisme du vendredi soir. Pour les caches CI, passez un CP_HOME_DIR déterministe ou des variables d’environnement de cache recommandées par CocoaPods, limitées au répertoire du job.

Avertissement hôte partagé : si deux jobs écrivent dans le même ~/Library/Caches/CocoaPods sans espace de noms, des téléchargements partiels peuvent survenir — isolez par $CI_JOB_ID ou par chemin de clone.

Caches, dossier Pods/ et disposition du workspace

Gardez Pods/ et la génération *.xcworkspace dans le clone du dépôt pour ce build. Sur espaces éphémères, ne mettez en cache vendor/bundle et le cache specs CocoaPods entre exécutions que si les checksums correspondent à Gemfile.lock + Podfile.lock. Sinon, invalidez agressivement — des caches specs périmés provoquent des erreurs de résolution obscures ressemblant à des problèmes réseau.

NVMe et hygiène multi-locataire

Les téléchargements CocoaPods peuvent ajouter des centaines de mégaoctets par install ; les monorepos à plusieurs Podfiles multiplient le coût. Sur hôtes 512 Go partagés, associez les passes du résolveur au guide disque de nettoyage simulateurs et archives. Si vous dépassez 70 % d’utilisation disque pendant les étapes pod, divisez les lanes ou passez à un nœud 1 To / 2 To via la page tarifs plutôt que d’élaguer sans fin en milieu de pipeline.

Builders régionaux : CDN et latence

L’accès au CDN des specs depuis Singapour ou Tokyo est en général excellent, mais proxys d’entreprise ou inspection TLS ajoutent des retries. Ajoutez des flags de retry à bundle install et documentez miroir ou proxy de cache si votre sécurité l’exige — par région pour que HK et US Est se comportent pareil.

Si vous migrez des lanes vers SwiftPM, comparez tailles de cache et sémantique de verrou avec résolution et cache SwiftPM. Pour la signature après résolution Pods, reprenez vos articles codesign auto/manuel — Bundler ne remplace pas les profils de provisioning.

FAQ : Bundler + CocoaPods sur Mac cloud

Question Réponse pratique
Puis-je utiliser CocoaPods Homebrew ? Évitez en CI — préférez les gems gérées par Bundler pour que les upgrades passent par revue de code, pas par bump accidentel de paquet.
Bundler 2 vs 1 ? Standardisez un major ; l’écart entre laptops et CI est une source fréquente de « ça marche en local ».
La CI doit-elle valider Pods/ ? Politique d’équipe — tout valider pour des builds hermétiques ou tout régénérer ; évitez le mi-chemin.

En bref : traitez CocoaPods comme tout autre toolchain compilateur — figez les versions, scopez les caches et passez toujours par bundle exec sur builders SSH partagés.

Louez des Mac CI Apple Silicon dédiés

SSH d’abord · HK · JP · KR · SG · US