Relancez vos builds

Vérifiez d’abord le répertoire développeur actif et la version, puis confirmez que la version de Xcode voulue est installée. L’exemple ci-dessous définit le répertoire système par défaut sur /Applications/Xcode.app ; pour une autre version, indiquez le chemin réel de l’application.

xcode-select -p
xcodebuild -version
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -version
xcrun --find swift

Un changement à l’échelle du système affecte les tâches lancées ensuite. Si vos pipelines utilisent différentes versions, définissez plutôt DEVELOPER_DIRdans l’environnement de chaque tâche, au lieu de laisser deux jobs modifier sans cesse le répertoire global.

DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer \
xcodebuild -list -workspace MyApp.xcworkspace

Après le changement, listez les schémas et lancez un Archive. Si des composants de plateforme manquent ou si la configuration initiale n’a pas été effectuée, initialisez la chaîne d’outils correspondante dans l’interface graphique de macOS avant de relancer l’automatisation.

Préparez un fichier d’export du certificat contenant la clé privée, le mot de passe de ce fichier et un profil de provisioning correspondant à l’identifiant de l’app et au mode de distribution. Un certificat sans la clé privée associée ne permet généralement pas de signer le code.

1. Sur le compte macOS qui exécute les builds, ouvrez « Accès aux trousseaux » et importez le certificat dans son trousseau.
2. Développez le certificat et vérifiez que la clé privée correspondante apparaît dessous. Utilisez la commande ci-dessous pour lister les identités de signature valides.
3. Installez le profil de provisioning conformément aux exigences de la version de Xcode utilisée. Dans les réglages de signature du projet, vérifiez l’équipe, le Bundle Identifier et le mode de distribution.
4. Vérifiez séparément les réglages de signature de l’app, des widgets et des extensions, puis lancez un Archive et validez l’export.

security find-identity -v -p codesigning

L’environnement du trousseau de l’utilisateur qui exécute la CI peut différer de celui de l’utilisateur du bureau à distance. Pour les builds sans intervention, déverrouillez correctement le trousseau dans le job et configurez les autorisations nécessaires. Récupérez le mot de passe depuis une variable protégée de la CI ; ne l’inscrivez ni dans le dépôt, ni dans la sortie des commandes, ni dans un ticket.

Si le build manuel réussit mais que la CI échoue, comparez d’abord l’utilisateur d’exécution et l’état du trousseau. Pour signaler une erreur de signature, indiquez uniquement le type de certificat, sa date d’expiration et les lignes d’erreur expurgées. Ne transmettez ni clé privée ni mot de passe de certificat.

Ne considérez pas une réinstallation comme une opération qui préserve vos fichiers. Elle peut effacer le système et le répertoire de travail. Avant d’en faire la demande, confirmez son périmètre via un ticket dans la console et sauvegardez vos données hors du nœud. À la fin de la location, le disque est effacé : le nœud ne peut alors plus servir à restaurer vos données.

La sauvegarde doit au minimum inclure le code source non poussé, la configuration du build, les artefacts nécessaires, les profils de provisioning et les éléments secrets protégés. DerivedData et les répertoires de téléchargement des dépendances sont régénérables, mais leur absence peut allonger le premier build après restauration.

Une sauvegarde n’est pas forcément restaurable. Extrayez-la dans un répertoire distinct, vérifiez le nombre de fichiers et les configurations essentielles, puis confirmez que vous pouvez récupérer le dernier artefact avant d’arrêter les tâches sur l’ancien nœud. Après la réinstallation, réinstallez la chaîne d’outils, restaurez l’environnement de signature et enregistrez le runner.

Connectez-vous au compte associé à la commande. Dans la console, vérifiez l’instance, la date d’expiration et les durées de renouvellement disponibles, puis réglez la facture affichée. Seuls le résultat confirmé par la console et la nouvelle période de location font foi, pas une capture d’écran du paiement ni la page affichée avant la fermeture du navigateur.

Les seuls moyens de paiement acceptés sont USDT-TRC20 et Visa / Mastercard / Amex (via Stripe). Tous les paiements sont en dollars ; la disponibilité effective des passerelles dépend de la réponse de l’interface serveur. Avant un paiement on-chain, vérifiez le réseau, le montant et les coordonnées du destinataire. Après un paiement par carte, retournez dans la console pour vérifier la facture.

Si l’état de la facture ne correspond pas à celui de l’instance, indiquez le numéro de commande, le numéro de facture et la référence de transaction. Ne payez pas une seconde fois pour tenter de corriger l’état et ne transmettez pas votre numéro de carte complet dans un ticket. Avant l’expiration, sauvegardez vos artefacts et fichiers nécessaires : le renouvellement ne remplace pas une sauvegarde.

Vérifiez d’abord dans la console l’adresse du nœud, le port, le nom d’utilisateur et l’état de l’instance. Distinguez un délai d’attente d’un échec d’authentification : dans le premier cas, vérifiez d’abord l’accès réseau ; dans le second, le nom d’utilisateur, le mot de passe ou la clé. SSH et VNC ont des paramètres de connexion distincts : ne confondez pas leurs ports.

ssh -v -p PORT USER@HOST

Remplacez PORT ,USER etHOST par les informations réelles. Si les journaux signalent un changement d’empreinte de l’hôte, vérifiez-en d’abord la cause à partir des informations fiables de la console ou d’un ticket ; ne désactivez pas la vérification de l’identité de l’hôte.

Le bureau à distance permet de vérifier l’interface graphique de macOS, le trousseau et les réglages de Xcode ; SSH convient à la ligne de commande et à la CI. Avant de transmettre des journaux, supprimez les informations sensibles des noms d’utilisateur, des adresses et des chemins locaux. Ne gardez que le type d’erreur et l’ordre dans lequel elle s’est produite.

Vérifiez ces quatre points : le runner est-il en ligne, ses tags correspondent-ils à ceux du job, le projet est-il autorisé à l’utiliser et le processus s’exécute-t-il avec le bon utilisateur ? Un enregistrement réussi établit une association, mais ne garantit pas que tous les jobs seront affectés automatiquement à ce nœud.

Lancez d’abord un job de test qui affiche uniquement les informations de la chaîne d’outils. Vérifiez l’utilisateur d’exécution, le répertoire et la version de Xcode, puis ajoutez l’installation des dépendances et la signature.

whoami
pwd
xcode-select -p
xcodebuild -version
security find-identity -v -p codesigning

Indiquez macOS, l’architecture de la puce et l’usage dans les tags, puis sélectionnez-les explicitement dans la configuration du projet. Pour la première intégration, limitez l’exécution à un seul job. Vérifiez que les caches, le trousseau et le répertoire des artefacts ne se chevauchent pas, puis augmentez progressivement le parallélisme. Le jeton d’enregistrement est un identifiant secret : ne le mettez ni dans un ticket ni dans les journaux de build.

Vérifiez d’abord que vous utilisez le bon workspace, un schéma partagé et la configuration Release. Archive et build pour simulateur ne suivent pas le même parcours ; vérifiez séparément la signature, l’architecture et les réglages d’export pour la cible appareil.

xcodebuild -list -workspace MyApp.xcworkspace
xcodebuild archive \
  -workspace MyApp.xcworkspace \
  -scheme MyApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath build/MyApp.xcarchive

Conservez la première erreur significative et son contexte : ne vous contentez pas de la conclusion « échec » à la fin du journal. Vérifiez séparément l’installation des dépendances, les phases de script, la signature et l’écriture sur le disque. Même si Archive réussit, validez les artefacts exportés : la création de l’archive ne signifie pas que le package distribuable est prêt.

Vérifiez d’abord l’espace utilisé et l’état des tâches, puis distinguez les caches régénérables des artefacts à conserver. Ne supprimez pas un répertoire dont dépend une tâche en cours et ne traitez pas le code source, les éléments de signature ou une archive pas encore téléversée comme des caches.

df -h
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/Archives

Définissez des règles de conservation distinctes pour les caches et les artefacts. Après leur suppression, la première compilation et la résolution des dépendances peuvent prendre plus de temps : considérez ce build comme un test à froid. Si l’espace manque durablement, mesurez la croissance du projet et des artefacts, puis choisissez un modèle plus adapté ou une option SSD supplémentaire.