Les scripts personnalisés de Xcode Cloud peuvent-ils réellement utiliser sudo ?

Non. La documentation Apple indique que les scripts personnalisés s’exécutent dans les limites de l’environnement de build fourni et qu’ils ne peuvent pas obtenir des privilèges administrateur avec sudo. Ajouter une saisie de mot de passe, répéter la commande ou modifier l’invite ne change donc pas la politique de la machine hébergée.

Comment installer une dépendance qui semble exiger les droits administrateur ?

Commencez par vérifier si l’outil existe déjà dans l’environnement Xcode Cloud, puis essayez une installation dans le répertoire du projet ou dans un dossier utilisateur. Les dépendances Swift Package Manager, les binaires versionnés dans le dépôt et certains outils Homebrew ne nécessitent pas forcément une modification système. Le besoin de sudo doit être démontré, pas supposé.

Pourquoi les fichiers produits par un script ne restent-ils pas entre deux builds ?

Xcode Cloud fournit un environnement de build temporaire. Un fichier créé pendant une exécution n’est donc pas un état permanent de la prochaine machine. Pour le conserver, archivez-le comme produit, versionnez une ressource adaptée dans le dépôt ou envoyez-le vers un stockage externe. Les caches volumineux et les états locaux persistants exigent un autre modèle.

Quand un Mac distant devient-il préférable à Xcode Cloud ?

La migration devient pertinente lorsque le pipeline dépend d’un service qui doit rester actif, d’une configuration macOS globale, d’un fichier conservé après redémarrage ou d’une reproduction fidèle d’un incident sur la même machine. Une double voie reste souvent plus prudente : tests et builds ordinaires dans Xcode Cloud, publication complexe sur un Mac distant contrôlable.

Xcode Cloud sudo indisponible : faut-il migrer vers un Mac distant en 2026 ?

Le choix recommandé est de conserver Xcode Cloud si le pipeline installe seulement des outils dans le projet, lit des variables d’environnement ou exécute des scripts avec les droits utilisateur ; en revanche, un Mac distant devient préférable dès qu’il faut des privilèges administrateur, un service permanent, des fichiers persistants ou une configuration macOS globale. Pour la plupart des petites équipes, la double voie — tests dans Xcode Cloud et publication complexe sur un Mac distant — limite davantage les risques qu’une migration précipitée.

Cette analyse s’adresse aux développeurs indépendants bloqués dans ci_post_clone.sh par sudo ou une erreur de permission, aux équipes qui doivent conserver un cache ou lancer un service auxiliaire, ainsi qu’aux responsables de publication qui comparent Xcode Cloud à un Mac distant contrôlable. Elle ne traite pas d’une accélération générale de compilation : le sujet est la frontière entre un script adaptable et un environnement qui ne peut plus reproduire le processus attendu.

Le message sudo révèle-t-il une vraie limite ou un simple défaut de script ?

Un échec dans un script personnalisé ne signifie pas automatiquement qu’Xcode Cloud est devenu inutilisable. Trois causes doivent être séparées : la commande est mal formée, le fichier n’est pas exécutable, ou l’action demande réellement une modification réservée à l’administrateur.

Un journal anonymisé peut ressembler à ceci :

+ sudo <commande-outil> --install
sudo: a password is required
sudo: no tty present and no askpass program specified

Dans cet exemple, la question n’est pas de savoir comment fournir le mot de passe. La question est de déterminer pourquoi l’installation veut écrire dans un emplacement système. La documentation Apple sur les scripts de build personnalisés de Xcode Cloud confirme que ces scripts ne peuvent pas utiliser sudo pour obtenir des privilèges administrateur.

La conséquence est opérationnelle : une boucle de tentatives ne contournera pas la limite. Une variable secrète contenant un mot de passe ne la contournera pas davantage. Il est également risqué de transformer le mot de passe en argument de commande, car il pourrait apparaître dans les journaux ou dans l’historique d’un outil.

Avant toute migration, le script doit être exécuté avec une commande de diagnostic minimale :

#!/bin/bash
set -euo pipefail

printf 'Utilisateur : '
id -un

printf 'Répertoire courant : '
pwd

printf 'Droits du dossier : '
ls -ld .

printf 'Outil recherché : '
command -v <outil-ou-commande> || true

Un résultat indiquant un utilisateur non administrateur n’est pas, à lui seul, un échec. Il devient bloquant uniquement si le processus exige une écriture hors du projet, l’installation d’un composant système ou une modification de réglages globaux de macOS.

La première décision est donc simple :

si l’erreur vient d’un chemin incorrect, d’un droit d’exécution absent ou d’une variable vide, corrigez le script ;
si l’outil peut être placé dans le dépôt ou dans un dossier utilisateur, restez sur Xcode Cloud ;
si l’installation modifie réellement macOS ou exige un compte administrateur, cessez de chercher un contournement et évaluez un Mac distant.

Installation des dépendances : outil système ou dépendance de projet ?

Les échecs d’installation sont souvent regroupés sous le mot « sudo », alors qu’ils n’ont pas tous la même cause. Un paquet Swift Package Manager qui ne se résout pas, une commande CocoaPods absente et un binaire qui tente d’écrire dans /usr/local sont trois problèmes différents.

Apple décrit dans sa documentation consacrée aux dépendances disponibles dans Xcode Cloud plusieurs mécanismes adaptés à un environnement automatisé : dépendances déclarées dans le projet, fichiers présents dans le dépôt et scripts exécutés aux étapes prévues du flux. Le principe à retenir est de rendre la dépendance déterministe et locale, plutôt que de modifier la machine à chaque exécution.

Un outil peut généralement rester dans Xcode Cloud lorsque les conditions suivantes sont réunies :

sa version est verrouillée dans le dépôt ;
son installation s’effectue dans un dossier appartenant à l’utilisateur du build ;
le script ajoute ce dossier au PATH sans modifier la configuration globale ;
le projet peut reconstruire l’environnement à partir d’un clone propre ;
aucune interaction humaine n’est nécessaire.

Exemple de méthode locale :

#!/bin/bash
set -euo pipefail

TOOLS_DIR="${HOME}/ci-tools/<outil>"
mkdir -p "${TOOLS_DIR}"

curl -L "<URL_BINAIRE_VERSIONNEE>" -o "${TOOLS_DIR}/<outil>"
chmod +x "${TOOLS_DIR}/<outil>"

export PATH="${TOOLS_DIR}:${PATH}"
<outil> --version

Les noms de dépôt, les URL, les versions et les identifiants doivent être remplacés par les valeurs du projet. L’exemple ne suppose pas que chaque outil puisse être installé ainsi. Il sert à vérifier si l’outil a besoin d’un répertoire système ou seulement d’un emplacement accessible.

Pour CocoaPods ou un utilitaire de génération, l’échec peut venir d’une résolution de dépendance, d’une incompatibilité de version ou d’un fichier de verrouillage absent. Pour Swift Package Manager, il faut plutôt inspecter le manifeste, les révisions utilisées et la disponibilité du réseau. Dans ces cas, migrer vers un Mac distant ne corrige pas nécessairement le défaut logique.

La migration est justifiée seulement si la documentation de l’outil impose une installation système, un composant macOS ou une modification qui doit survivre à plusieurs exécutions. Dans le cas contraire, le critère d’acceptation est plus utile qu’un changement de plateforme : un clone propre doit installer les dépendances, compiler l’application et produire le même artefact sans saisie manuelle.

Fichiers temporaires, caches et résultats de génération

Un autre blocage apparaît lorsque le script fonctionne une fois, puis perd un fichier généré lors du build suivant. Cette situation n’est pas nécessairement un bug du script. Xcode Cloud exécute le flux dans un environnement temporaire ; le fichier créé pendant une exécution ne doit donc pas être considéré comme un disque persistant.

Les étapes et variables d’environnement de Xcode Cloud permettent de structurer le flux, mais elles ne transforment pas automatiquement le répertoire de travail en stockage durable. Le fichier doit être dirigé vers le bon mécanisme :

une ressource reproductible doit être versionnée dans le dépôt ;
un fichier produit par le build doit être copié dans les artefacts prévus ;
une donnée volumineuse ou sensible doit être envoyée vers un stockage externe autorisé ;
un cache doit être recréé ou restauré selon une stratégie explicite ;
un état de diagnostic doit être exporté avec le résultat de l’exécution.

Le script suivant illustre une séparation saine entre génération et export :

#!/bin/bash
set -euo pipefail

GENERATED_DIR="${CI_PRIMARY_REPOSITORY_PATH}/Generated"
EXPORT_DIR="${CI_RESULT_BUNDLE_PATH:-${CI_PRIMARY_REPOSITORY_PATH}/BuildOutput}"

mkdir -p "${GENERATED_DIR}" "${EXPORT_DIR}"

<commande-de-generation> \
  --output "${GENERATED_DIR}/<fichier-genere>"

cp "${GENERATED_DIR}/<fichier-genere>" \
   "${EXPORT_DIR}/<fichier-genere>"

Les variables exactes disponibles doivent être contrôlées dans la référence officielle des variables d’environnement. Il faut aussi vérifier à quelle étape le fichier est créé et à quelle étape il est consommé. Un fichier produit après l’étape qui l’attend ne peut pas être récupéré par une simple modification de permission.

Le choix dépend du type d’état :

un petit fichier de configuration dérivé du dépôt peut être régénéré à chaque build ;
un fichier de licence ou un secret ne doit pas être placé en clair dans le dépôt ;
un cache de compilation peut être utile, mais il ne doit pas devenir la seule source de vérité ;
un état local nécessaire à la reproduction d’un incident exige une stratégie d’export ;
une base de données de test qui doit rester active dépasse le rôle d’un simple fichier intermédiaire.

Si le projet exige un cache volumineux conservé sur la même machine, ou un état qui doit être disponible après une nouvelle exécution, le Mac distant prend un avantage structurel. Toutefois, cet avantage crée une responsabilité : sauvegarde, rotation des secrets, surveillance du disque et procédure de restauration deviennent nécessaires.

Point de vigilance : un Mac distant n’est pas automatiquement persistant parce qu’il est accessible à distance. Avant de déplacer le pipeline, vérifiez la conservation des volumes, le comportement après redémarrage et la possibilité de recréer l’environnement à partir d’un script.

Services en arrière-plan et réglages macOS

Les tâches qui nécessitent un processus permanent sont celles qui franchissent le plus nettement la frontière entre CI hébergée et machine contrôlable. Une base de données locale, un serveur de simulation, un démon de génération audio ou vidéo, un service de test et une extension système ne présentent pas les mêmes exigences.

Un service peut rester dans Xcode Cloud lorsqu’il est lancé uniquement pour la durée d’un build, avec les droits utilisateur, sur un port local et avec une commande d’arrêt fiable :

#!/bin/bash
set -euo pipefail

<service-local> \
  --port <PORT_TEST> \
  > "${TMPDIR}/<service>.log" 2>&1 &

SERVICE_PID=$!
trap 'kill "${SERVICE_PID}" 2>/dev/null || true' EXIT

for attempt in 1 2 3 4 5; do
  if curl --fail "http://127.0.0.1:<PORT_TEST>/health"; then
    break
  fi
  sleep 2
done

<commande-de-test>

Les cinq tentatives de l’exemple constituent une politique de robustesse du script, pas une garantie fournie par Xcode Cloud. Le nombre doit être ajusté au temps de démarrage réel du service. Le processus doit également être arrêté, afin qu’il ne masque pas un échec ou ne laisse pas de ressource inutilisée.

La migration vers un Mac distant devient plus cohérente dans les cas suivants :

le service doit rester disponible entre deux builds ;
il faut installer un composant système ou une extension ;
le pipeline dépend d’un réglage global de macOS ;
plusieurs étapes doivent retrouver le même état local ;
l’équipe doit reproduire un incident sur la même machine ;
le processus doit être relancé automatiquement après un redémarrage.

Une session graphique distante ne remplace pas un service en arrière-plan. VNC permet de contrôler le bureau. SSH permet d’exécuter des commandes. Aucun des deux ne garantit qu’un processus lancé dans une session interactive survivra à la fermeture de celle-ci. Le démarrage automatique, la surveillance et les journaux doivent donc être conçus séparément.

Pour les projets audio, vidéo ou design, cette distinction est particulièrement importante. Un générateur de ressources qui dépend d’un plug-in installé au niveau système, d’un volume de médias monté ou d’un service auxiliaire stable ne se traite pas comme une simple dépendance Swift. Le Mac distant peut alors servir de poste de génération contrôlé, tandis que les tests de code restent dans Xcode Cloud.

Signature et publication : sudo n’est souvent pas le vrai problème

Un Archive qui échoue ou une publication App Store Connect interrompue peut donner l’impression qu’il faut des droits administrateur. En réalité, les causes les plus fréquentes se situent dans le trousseau, les certificats, les profils de provisioning, les variables secrètes ou l’accès non interactif à la clé privée.

Apple documente la distribution des certificats de signature d’équipe ainsi que les certificats gérés dans le cloud. Ces mécanismes concernent l’identité de signature et l’accès aux ressources de développement ; ils ne donnent pas de privilèges administrateur au script.

Un diagnostic minimal doit vérifier les éléments sans exposer les secrets :

#!/bin/bash
set -euo pipefail

test -n "${APP_STORE_CONNECT_KEY_ID:-}" \
  || { echo "Clé absente : APP_STORE_CONNECT_KEY_ID"; exit 1; }

test -n "${APP_STORE_CONNECT_ISSUER_ID:-}" \
  || { echo "Émetteur absent : APP_STORE_CONNECT_ISSUER_ID"; exit 1; }

test -f "${APP_STORE_CONNECT_KEY_PATH:-}" \
  || { echo "Fichier de clé absent"; exit 1; }

security find-identity -v -p codesigning

La sortie complète de security find-identity ne doit pas être publiée dans un journal partagé si elle révèle des informations inutiles. Les valeurs de clé, identifiants d’équipe, identifiants d’application et jetons doivent rester des espaces réservés dans les exemples et des variables protégées dans le flux réel.

Avant de modifier les règles d’accès du trousseau, il faut noter l’impact et prévoir le retour arrière. Une autorisation trop large peut permettre à n’importe quel processus du build d’utiliser une clé privée. Une autorisation trop stricte peut bloquer xcodebuild sans que sudo soit impliqué.

La décision est alors la suivante :

si l’identité de signature est absente, corrigez les secrets et les profils ;
si la clé existe mais reste inaccessible en mode non interactif, corrigez la configuration du trousseau ;
si l’Archive et la signature passent mais que l’envoi échoue, inspectez le jeton et l’étape de publication ;
si le processus exige une modification durable du trousseau ou une intervention locale non automatisable, testez un Mac distant avec une politique de sécurité documentée.

La carte de décision : corriger, doubler ou migrer

Le choix ne doit pas reposer sur le seul message sudo. Il doit être arrêté après un test complet du dépôt et de la chaîne de publication. La carte suivante fournit un embranchement directement applicable :

Si le script installe un outil dans le projet ou dans le dossier utilisateur, alors corrigez Xcode Cloud. Sinon, passez au critère des services.
Si les fichiers peuvent être régénérés, archivés comme artefacts ou envoyés vers un stockage externe, alors restez sur Xcode Cloud. Sinon, évaluez un Mac distant persistant.
Si les services sont lancés uniquement pendant le build avec les droits utilisateur, alors conservez-les dans le flux après un test de nettoyage. Sinon, déplacez cette partie vers une machine contrôlable.
Si l’échec de signature vient des certificats, du trousseau ou des variables, alors corrigez la conception des secrets. Sinon, documentez la dépendance à la configuration macOS.
Si l’équipe peut reproduire l’échec sur un clone propre, alors la migration n’est pas encore démontrée. Sinon, faites un essai court sur un Mac distant pour développement iOS.
Si les builds ordinaires et les tests sont stables dans Xcode Cloud mais que l’Archive complexe reste fragile, alors adoptez la double voie. Sinon, gardez un seul environnement jusqu’à ce que la cause soit isolée.

Cette double voie sépare les responsabilités : Xcode Cloud absorbe les builds reproductibles et les tests courants ; le Mac distant prend en charge la publication qui dépend d’un environnement durable, d’un service local ou d’un réglage contrôlé. Les développeurs peuvent consulter les formules de location de Mac pour comparer la durée d’essai et le niveau d’engagement adapté à cette validation.

La validation finale doit couvrir l’installation depuis un dépôt propre, la génération des ressources, l’Archive, la signature, l’envoi, la récupération des artefacts et le comportement après redémarrage. Un seul Build Succeeded ne prouve pas qu’un environnement est exploitable sans surveillance.

Procédure de migration sans perdre la traçabilité

Une migration prudente commence par une copie minimale du pipeline, pas par le déplacement immédiat de toute la production.

Figez le cas d’échec. Conservez le journal anonymisé, le commit concerné, l’étape du flux et la commande exacte. Remplacez les mots de passe, jetons, chemins privés, identifiants d’équipe et identifiants d’application par des espaces réservés.
Classez chaque dépendance. Pour chaque outil, indiquez s’il est intégré au projet, installé dans un dossier utilisateur, écrit dans un emplacement système ou lancé comme service. Cette liste sépare les corrections simples des dépendances réellement liées à macOS.
Reproduisez l’installation. Lancez le script sur un environnement propre. Sur le Mac distant, utilisez un utilisateur dédié et documentez les commandes d’installation. Ne copiez pas silencieusement un état manuel qui empêcherait une restauration ultérieure.
Configurez les secrets avec le minimum de droits. Importez uniquement les certificats et clés nécessaires à l’Archive. Vérifiez l’accès non interactif au trousseau. Préparez une procédure de révocation si une clé a été exposée ou si la politique d’accès doit être modifiée.
Exécutez un Archive signé. Un build Debug ne suffit pas. Le test doit utiliser le schéma de publication réel, le profil approprié et les mêmes variables que le processus automatisé.
Testez l’envoi et le retour d’erreur. Vérifiez que le téléversement ne dépend pas d’une session VNC ouverte. Les journaux doivent permettre d’identifier une erreur de certificat, de réseau ou de paquet sans révéler les secrets.
Redémarrez puis recommencez. Cette étape distingue une configuration reproductible d’un poste réparé manuellement. Si le service, le trousseau ou la dépendance disparaît après redémarrage, le pipeline n’est pas encore prêt pour l’exploitation.
Définissez le retour arrière. Tant que le Mac distant n’a pas passé la chaîne complète, gardez Xcode Cloud pour les tâches qui fonctionnent déjà. La double voie évite qu’une migration expérimentale bloque les tests quotidiens.

Un Mac distant devient donc une réponse à une contrainte démontrée, pas à un mot-clé dans le journal. Pour comparer les options de commande et d’accès, la page Mac mini distant en français peut servir de point de départ, mais la configuration retenue doit être validée avec le projet réel et ses dépendances.

FAQ

Les scripts personnalisés de Xcode Cloud peuvent-ils utiliser sudo ?

Non. Un script personnalisé reste soumis aux droits de l’environnement de build fourni. Il ne peut pas obtenir des privilèges administrateur avec sudo. Si la commande fonctionne uniquement après modification d’un emplacement système, il faut soit installer l’outil autrement dans un espace utilisateur, soit déplacer cette étape vers une machine administrable.

Comment installer une dépendance nécessitant apparemment les droits administrateur ?

Commencez par vérifier la documentation de l’outil et le chemin d’installation. Une dépendance de projet peut souvent être placée dans le dépôt ou dans un dossier utilisateur, tandis qu’un composant macOS peut réellement exiger une installation globale. Testez séparément la résolution du projet et l’installation de l’outil avant de conclure à une limite de Xcode Cloud.

Pourquoi un fichier généré disparaît-il au build suivant ?

Le répertoire de travail d’un flux Xcode Cloud ne doit pas être considéré comme un disque permanent. Un fichier temporaire doit être régénéré, exporté comme artefact ou envoyé vers un stockage externe. Si le pipeline dépend d’un cache volumineux ou d’un état local conservé entre les exécutions, cette exigence doit être incluse dans l’évaluation d’un Mac distant.

À partir de quel moment faut-il migrer vers un Mac distant ?

La migration est pertinente lorsque le pipeline dépend d’un service permanent, d’un réglage macOS global, d’un accès administrateur ou d’un fichier qui doit survivre aux exécutions et aux redémarrages. Si seuls les tests et les builds ordinaires sont concernés, conservez Xcode Cloud et déplacez éventuellement l’Archive complexe sur un Mac distant dans une organisation à double voie.

Choisir le bon environnement sans déplacer le mauvais problème

Xcode Cloud reste le meilleur choix lorsque les dépendances sont déclarées, les scripts fonctionnent sans privilèges élevés et les artefacts sont exportés correctement. Le service devient moins adapté lorsqu’il faut conserver un état local, faire tourner une base de données en permanence ou modifier profondément macOS. Dans ce cas, répéter sudo ne fait que retarder le diagnostic.

Un environnement local acheté peut offrir davantage de contrôle, mais il immobilise du matériel, demande une maintenance permanente et n’est pas toujours pertinent pour un besoin temporaire ou une validation de publication. Un Mac distant apporte ce contrôle sans imposer immédiatement l’achat d’une machine dédiée ; il faut néanmoins vérifier la persistance, les redémarrages, les sauvegardes et la sécurité des clés.

Pour un besoin ponctuel de test, d’Archive ou de migration, la location d’un Mac auprès de SFTPMAC peut offrir une étape de validation plus souple qu’un achat précipité. La démarche recommandée reste de reprendre le script en échec, de prouver la dépendance aux privilèges ou à la persistance, puis de valider une courte chaîne complète sur le Mac distant avant d’y transférer les publications régulières.