Comment exporter un xcresult depuis un CI Mac distant ? Guide 2026

Le test échoue dans le CI Mac distant, mais aucun paquet de résultats n’apparaît dans les artefacts ?

Action immédiate : avant la prochaine exécution, définissez dans xcodebuild test un chemin .xcresult propre à la tâche, puis téléversez ce paquet même si les tests échouent. Pour valider le circuit, téléchargez-le et ouvrez-le réellement : le statut du travail ne prouve pas, à lui seul, que le résultat est exploitable.

Ce guide s’adresse aux personnes qui maintiennent un CI Mac et doivent récupérer les résultats générés après la fin d’un travail.
Il est également destiné aux ingénieurs de test qui cherchent les détails d’échec, les journaux ou les données de couverture dans le paquet.
Les responsables des livraisons et de la plateforme y trouveront des critères de nommage, de conservation et d’accès.

Pour le mainteneur CI : repérer l’étape qui produit le paquet

Un paquet de résultats Xcode n’est ni le journal standard de la tâche ni l’archive destinée à la distribution. Il faut d’abord établir que le travail a exécuté des tests, puis vérifier que la commande correspondante a demandé ou produit le paquet à l’emplacement retenu.

La documentation Apple décrit les résultats de test et leur consultation dans Xcode ; les informations rapportées peuvent comprendre le résultat des tests et des éléments associés à leur analyse. Consultez la documentation Apple sur l’exécution des tests et l’interprétation des résultats pour déterminer ce que votre projet peut examiner dans l’interface de résultats. Apple présente également le paquet de résultats comme un format introduit pour conserver des informations de test dans les notes de Xcode 11.

Commencez par lire la commande complète du travail, et non uniquement son nom dans l’interface du CI. Repérez l’invocation de xcodebuild, ses options de test, le répertoire courant et les étapes qui s’exécutent ensuite. Une compilation seule peut produire des journaux ou d’autres fichiers sans générer le résultat de test que vous cherchez. De même, une archive de livraison ne remplace pas un paquet .xcresult.

Pour isoler la cause, consignez dans le journal la commande effective et le chemin de sortie attendu, sans y imprimer de secrets. Puis comparez ce chemin à la liste des fichiers présents à la fin de l’étape. Si le paquet n’existe pas sur le disque, l’étape de téléversement ne peut pas le retrouver ; si le paquet existe, mais ne figure pas dans l’artefact, examinez plutôt la sélection de fichiers et la condition d’exécution du téléversement.

Pour l’ingénieur de build : choisir un chemin distinct et vérifiable

L’option -resultBundlePath permet de préciser où xcodebuild doit enregistrer le paquet de résultats d’un test. La référence Apple des outils en ligne de commande de Xcode est à consulter pour les paramètres applicables à la version de Xcode installée. Le principe opérationnel reste le même : choisissez un chemin déterministe, identifiable dans le journal et distinct du code source.

Voici une structure de commande à adapter à votre projet. Les variables sont volontairement des espaces réservés : remplacez-les par les valeurs définies dans votre travail, plutôt que de reprendre un nom partagé entre plusieurs exécutions.

RESULTS_DIR="<répertoire-des-résultats>"
RESULT_NAME="<identifiant-de-la-tâche>"
xcodebuild test \
  -scheme "<schéma>" \
  -destination "<destination-de-test>" \
  -resultBundlePath "$RESULTS_DIR/$RESULT_NAME.xcresult"

Rangez le paquet dans un répertoire réservé aux résultats, hors des sources suivies par Git et hors d’un emplacement déjà occupé par un résultat antérieur. Un chemin relatif peut dépendre du répertoire depuis lequel le travail lance la commande ; si vous en utilisez un, rendez le répertoire courant explicite dans le script. Un chemin absolu construit à partir d’une variable de travail rend souvent cette dépendance plus facile à diagnostiquer.

Le nom doit permettre de relier le fichier à son exécution, à son commit et à la tâche de test, tout en restant utilisable par votre étape de téléversement. Évitez un nom fixe tel que result.xcresult lorsque des exécutions peuvent se chevaucher ou réutiliser le même espace de travail. Si des tests parallèles écrivent simultanément, donnez à chacun un chemin distinct ; sinon, un résultat peut être incomplet, remplacé ou difficile à attribuer.

Point de contrôle : avant d’ajouter le téléversement, faites apparaître dans le journal le chemin calculé, puis vérifiez que le paquet existe à cet emplacement après l’étape de test. Un chemin deviné dans une étape ultérieure ne suffit pas.

Pour le responsable du flux de travail : téléverser même après un échec

L’étape de téléversement doit suivre l’étape de test, mais ne doit pas être conditionnée exclusivement à sa réussite. Dans GitHub Actions, les conditions d’exécution déterminent si une étape s’exécute après l’échec d’une étape précédente ; la référence officielle des expressions décrit les fonctions utilisables dans ces conditions.

Un fragment schématique peut ressembler à ceci. Remplacez le nom de l’action par une version que vous avez vérifiée et maintenez conformément à votre politique de dépendances.

- name: Exécuter les tests
  run: |
    xcodebuild test \
      -scheme "<schéma>" \
      -destination "<destination-de-test>" \
      -resultBundlePath "<répertoire-des-résultats>/<nom-de-tâche>.xcresult"

- name: Téléverser le paquet de résultats
  if: ${{ !cancelled() }}
  uses: actions/upload-artifact@<version-validée>
  with:
    name: "<exécution>-<commit>-<tâche-de-test>"
    path: "<répertoire-des-résultats>/<nom-de-tâche>.xcresult"

La condition présentée vise à ne pas laisser un échec de test empêcher automatiquement l’étape suivante, tout en distinguant le cas d’une exécution annulée. Vérifiez que ce comportement correspond à vos règles d’annulation et de nettoyage. Le téléversement doit recevoir le chemin exact du paquet ; un motif trop étroit, un répertoire de travail différent ou un nom calculé autrement peut laisser l’étape sans fichier à joindre.

La documentation GitHub distingue les artefacts de flux de travail, qui servent à conserver et à partager des fichiers produits par une exécution, du cache, qui répond à un autre besoin. Les instructions officielles sur la persistance des données de flux de travail expliquent la transmission et le téléchargement des artefacts. Les concepts d’artefacts de flux de travail précisent le rôle de ces fichiers comme sorties d’une exécution.

Ne comptez donc pas sur le cache pour archiver les preuves d’un test : il ne remplace pas un artefact téléchargeable associé à une exécution. Vérifiez aussi la configuration de l’action de téléversement et sa façon de traiter le chemin fourni. Elle peut sélectionner un fichier, un répertoire ou plusieurs chemins selon sa configuration ; les motifs doivent réellement inclure le paquet .xcresult, et pas seulement les journaux voisins.

Pour l’ingénieur de test : télécharger et lire le résultat

Le téléchargement n’est que la première vérification. Depuis l’exécution concernée, récupérez l’artefact associé à la tâche, puis ouvrez son contenu sur un Mac équipé de Xcode. GitHub documente le téléchargement depuis l’interface et les méthodes disponibles dans son guide consacré au téléchargement des artefacts de flux de travail.

Un paquet .xcresult peut contenir une structure que votre navigateur ou votre gestionnaire de fichiers ne présente pas comme un document ordinaire. N’en concluez pas qu’il est endommagé parce qu’il ne s’ouvre pas comme un fichier texte. Essayez de l’ouvrir dans Xcode, puis utilisez xcresulttool pour examiner les informations disponibles. Les commandes et les options pouvant varier selon la version installée, consultez l’aide locale de l’outil et la documentation Apple au lieu de copier une syntaxe trouvée pour une autre version.

Pour chaque résultat récupéré, contrôlez que le nom et le commit correspondent à la tâche attendue. Examinez ensuite le résumé, les tests en échec et les détails nécessaires au diagnostic. Si votre projet s’appuie sur la couverture ou sur des pièces jointes, vérifiez explicitement leur présence et leur lisibilité : le simple fait d’avoir téléchargé un artefact ne prouve pas que toutes les données dont l’équipe a besoin y figurent.

FAQ sur l’export du résultat de test

Comment définir le chemin du paquet de résultats avec xcodebuild test ?
Ajoutez -resultBundlePath à la commande de test et fournissez un chemin explicite vers un fichier .xcresult. Placez-le hors des sources et donnez à chaque tâche concurrente son propre emplacement. Vérifiez ensuite le chemin calculé dans le journal et confirmez que le paquet existe avant que l’action de téléversement ne le sélectionne.

Pourquoi le paquet d’un CI Mac distant n’apparaît-il pas dans les artefacts ?
Vérifiez si le test a produit le paquet, si l’étape de téléversement a été exécutée après l’échec et si son chemin correspond au fichier réel. Examinez aussi les motifs de sélection et le répertoire de travail. Le statut rouge du travail ne permet pas, à lui seul, de savoir si le fichier a été créé ou téléversé.

Comment télécharger puis ouvrir le paquet depuis GitHub Actions ?
Dans l’exécution concernée, téléchargez l’artefact associé au test, puis ouvrez le paquet avec Xcode sur macOS ou examinez-le avec xcresulttool. Confirmez que son résumé et ses détails d’échec correspondent au commit et à la tâche concernés. Vérifiez séparément la couverture ou les pièces jointes si votre équipe en dépend.

Comment conserver le résultat quand les tests échouent ?
Séparez le téléversement de la commande de test et configurez sa condition pour qu’un échec ne le bloque pas. Sélectionnez le chemin .xcresult exact et contrôlez l’artefact d’une exécution en échec. Si le travail est annulé, appliquez la politique prévue pour ce cas au lieu de supposer que le nettoyage et la conservation se comportent comme après un échec ordinaire.

Pour le responsable de plateforme : encadrer le nommage, la durée et les accès

Un paquet de résultats aide au diagnostic, mais peut également révéler des noms de tests, des détails d’implémentation, des journaux ou des éléments propres au projet. Traitez-le comme une sortie de développement dont l’accès doit être limité aux personnes qui en ont besoin ; ne le rendez pas public au seul motif qu’il s’agit d’un artefact de CI.

Définissez une convention qui relie clairement chaque paquet à son exécution, au commit et à la tâche de test. Le nom affiché dans la liste des artefacts doit rester distinct du nom interne du fichier si cela facilite le téléchargement ou le traitement automatisé. Si un identifiant est sensible, utilisez une référence interne adaptée plutôt que d’exposer une information confidentielle dans le nom.

La période de conservation dépend de la configuration de la plateforme et des règles du dépôt ou de l’organisation. Ne supposez pas qu’une valeur par défaut convient à votre équipe : vérifiez le réglage effectif, puis choisissez une durée compatible avec vos besoins de diagnostic, vos exigences de sécurité et votre capacité de stockage. Le cache et le paquet de résultats ne répondent pas au même usage ; la politique de cache ne doit pas définir par accident la durée de conservation des preuves de test.

Pour le responsable de livraison : décider selon les preuves observées

Avant de conserver un mécanisme d’export, passez par ces conditions de décision :

• Si le travail exécute réellement des tests et qu’un paquet apparaît au chemin défini, conservez ce chemin et reliez son nom à l’exécution et à la tâche. Sinon, corrigez la commande de test ou son contexte d’exécution avant de modifier l’action de téléversement.
• Si le paquet existe sur le Mac, mais pas parmi les artefacts, contrôlez la condition de l’étape, le chemin transmis et les motifs de sélection. Sinon, si le paquet n’existe déjà pas sur le Mac, cherchez du côté de l’invocation de test et du chemin de sortie.
• Si l’artefact est téléchargeable et lisible dans Xcode ou par xcresulttool, vérifiez les détails utiles au diagnostic et les pièces requises par votre projet. Sinon, traitez l’export comme non validé, même si le flux de travail indique que l’étape de téléversement s’est terminée.
• Si les annulations doivent aussi préserver des fichiers, établissez une règle distincte et testez-la selon le comportement documenté de votre plateforme. Sinon, ne confondez pas une exécution annulée avec un échec de test ordinaire.

Pour l’acceptation, lancez une tâche dont les tests réussissent, puis une tâche où un test échoue de façon contrôlée. Dans les deux cas, recherchez le paquet sur le Mac, confirmez que l’étape de téléversement l’a sélectionné, téléchargez l’artefact et ouvrez-le. Cette vérification distingue quatre causes souvent confondues : résultat jamais généré, téléversement non exécuté, chemin ou motif inadéquat, et artefact devenu indisponible selon la politique de conservation.

Si votre CI repose sur un poste partagé que vous devez entretenir vous-même, les mises à jour, l’accès distant, la continuité d’exécution et la récupération des fichiers restent à votre charge. Un Mac mini local peut convenir si vous avez besoin d’interfaces physiques ou d’une machine dédiée sur site ; en revanche, il vous faut assumer son acquisition, son exploitation et son remplacement. Pour des campagnes de test ponctuelles ou un environnement macOS distinct du poste principal, la location d’un Mac distant peut éviter cet investissement matériel, tout en laissant à votre équipe le soin de définir les chemins, les artefacts et les droits du dépôt. Vous pouvez consulter les options de Mac distant proposées par VPSMAC et comparer leur adéquation à la fréquence de vos builds et à vos responsabilités d’exploitation. Le site de VPSMAC permet également d’examiner l’offre avant de décider si ce mode d’accès convient à votre chaîne CI.