Comment archiver automatiquement les artefacts de compilation Xcode Cloud ? Guide 2026

Téléchargez les artefacts de compilation Xcode Cloud dès que le build est terminé, vérifiez les fichiers, puis archivez-les dans un stockage contrôlé par votre équipe. Le téléchargement peut être manuel depuis Xcode ou App Store Connect, ou automatisé avec l’App Store Connect API ; dans les deux cas, ne traitez pas l’adresse temporaire fournie par l’API comme une archive durable.

Ce guide s’adresse aux équipes qui doivent retrouver un échec historique, conserver une preuve de test ou diagnostiquer un incident après la fin d’accès aux fichiers hébergés.
Il convient aussi aux ingénieurs CI qui veulent définir qui télécharge, où les fichiers sont stockés et comment ils sont supprimés.

Définir ce qui mérite d’être conservé

Un build terminé ne signifie pas que chaque fichier produit doit être conservé sans limite. Commencez par associer chaque type d’artefact à un usage concret : reprendre une publication, comprendre un crash, examiner un test ou fournir une preuve à une équipe de validation.

La documentation Apple présente les informations de build et les artefacts accessibles dans Xcode Cloud, ainsi que les voies de téléchargement depuis Xcode, App Store Connect ou l’API. Apple indique que ces informations et artefacts sont accessibles pendant une durée maximale de 30 jours ; cette limite est documentée dans le guide Apple de configuration d’un flux Xcode Cloud. Elle concerne l’accès aux éléments côté Apple. Elle ne constitue pas une politique de conservation pour le stockage interne de votre équipe.

Classez les fichiers selon leur utilité opérationnelle :

• Archive ou binaire distribué : utile pour identifier exactement ce qui a été remis à la validation ou publié. Vérifiez les exigences du processus de publication avant de décider si le fichier doit être gardé.
• Symboles de débogage : à conserver lorsqu’ils sont nécessaires pour interpréter des rapports de crash correspondant à la version construite. Associez-les sans ambiguïté au build concerné.
• Journaux de compilation : précieux pour comprendre une erreur qui n’apparaît plus dans les builds suivants. Ils peuvent aussi révéler des chemins, des noms de projets ou des informations de configuration.
• Résultats de test : gardez ceux qui permettent de retrouver une régression, de documenter une validation ou de comparer le comportement attendu et observé.
• Métadonnées de build : identifiant, action, branche et référence du commit forment le lien de traçabilité entre le contenu téléchargé et le changement qui l’a produit.

Pour une application créative — par exemple un outil audio, vidéo ou de design — la sélection dépend aussi du travail réalisé après compilation. Une équipe peut avoir besoin de retrouver un binaire d’essai et son résultat de test, sans pour autant conserver chaque export intermédiaire ni tous les journaux de développement. Écrivez cette distinction dans votre procédure, plutôt que de laisser chaque personne choisir au cas par cas.

Choisir la méthode de récupération selon le travail

La récupération manuelle est adaptée à un volume faible, à une vérification humaine ou à un incident ponctuel. L’automatisation convient mieux lorsqu’un processus d’équipe exige que chaque build important soit associé à une copie contrôlée. Le tableau compare les deux voies sans supposer qu’Apple déclenche ou garantit un archivage automatique dans votre stockage.

La consultation manuelle est décrite dans la documentation Apple sur Xcode Cloud et l’archivage. Dans Xcode ou App Store Connect, ouvrez le rapport du build concerné, examinez ses actions et identifiez les fichiers utiles avant de les télécharger. Ensuite, rangez-les dans un répertoire dont l’emplacement est connu de l’équipe. Un téléchargement effectué sur le poste d’une seule personne, sans copie organisée ni responsable, n’est pas encore un processus d’archivage.

La voie API apporte de la répétabilité, mais ajoute des responsabilités. L’équipe doit gérer une clé, l’autorisation des requêtes, les erreurs de téléchargement, le contrôle des fichiers et le stockage. Il faut donc automatiser la chaîne complète plutôt que la seule récupération d’une adresse.

Préparer l’accès API avant la fin du build

L’App Store Connect API utilise une authentification documentée par Apple. La création d’une clé et la génération des jetons de requête doivent suivre les procédures officielles : consultez les instructions Apple pour créer une clé API App Store Connect et pour générer les jetons d’authentification des requêtes.

Avant de brancher l’API à un flux de travail, établissez les règles suivantes :

• Attribuez la clé à un compte et à un usage clairement identifiés. Ne la partagez pas dans le dépôt du projet.
• Stockez le matériel de signature dans le gestionnaire de secrets déjà approuvé par l’organisation, ou dans un emplacement à accès restreint.
• Limitez les personnes et les processus autorisés à consulter ou renouveler les secrets.
• Empêchez l’affichage du jeton et des éléments de signature dans les journaux de tâche. Un échec HTTP ne justifie pas d’imprimer les en-têtes complets.
• Testez l’authentification dans un environnement contrôlé avant de l’utiliser pour archiver des builds importants.

La documentation de l’API distingue les ressources des flux de travail et des builds. Le référentiel Apple des ressources Xcode Cloud pour les flux et les builds aide à identifier les relations disponibles. Vérifiez les autorisations applicables à votre compte et à votre équipe dans la documentation actuelle : ne déduisez pas qu’une clé fonctionnelle pour une opération possède automatiquement tous les droits nécessaires à la lecture et au téléchargement des artefacts.

Construire le flux de récupération après le build

Le principe est de partir d’un build terminé, d’en retrouver les actions, de demander la liste des artefacts utiles, puis de télécharger et de classer les fichiers. Les routes et attributs ci-dessous sont des points d’appui pour lire la documentation, pas une promesse qu’un déclencheur particulier sera fourni par Apple.

Les ressources d’API permettent d’examiner les actions d’un build et leurs artefacts. Pour lister les artefacts associés à une action, consultez la référence Apple de la ressource d’artefacts d’une action de build. Pour connaître les attributs exposés, notamment les informations descriptives et le lien de téléchargement, reportez-vous à la définition Apple des attributs d’un artefact. La ressource individuelle dispose également d’une référence dédiée à la lecture d’un artefact.

Organisez la procédure en phases vérifiables :

• Déclenchement : choisissez le mécanisme qui détecte qu’un build pertinent est terminé. Il peut s’agir d’une étape de votre orchestration ou d’une tâche de contrôle périodique. Documentez ce choix et ne supposez pas qu’Apple garantit un événement d’archivage vers votre système.
• Repérage : identifiez le build dans le contexte attendu, puis récupérez les actions qui lui sont associées. Enregistrez les identifiants retournés par l’API pour pouvoir expliquer quelle ressource a été consultée.
• Sélection : comparez le nom et le type déclarés pour chaque artefact à votre règle de conservation. Écartez les fichiers sans utilité définie, mais consignez ce qui a été omis si cette décision a une importance pour l’audit ou le diagnostic.
• Téléchargement : utilisez l’adresse obtenue pour transférer le contenu immédiatement vers une zone de transit contrôlée. Apple précise que les adresses de téléchargement des artefacts ne sont valables que pendant une durée limitée ; la référence officielle de l’API des artefacts doit primer sur toute hypothèse de lien permanent.
• Enregistrement : après vérification, déplacez les fichiers vers l’emplacement final et écrivez les métadonnées de traçabilité à côté. Le processus doit signaler un échec si un fichier attendu manque ou si le téléchargement est interrompu.

L’automatisation ne doit pas dépendre d’une adresse conservée dans une base comme si elle identifiait un fichier permanent. Enregistrez plutôt l’identifiant du build, l’action, le type d’artefact et le chemin de la copie effectivement archivée. Si le système de stockage possède ses propres identifiants ou règles de versionnement, consignez-les aussi.

Vérifier les fichiers avant de considérer l’archivage terminé

Une réponse API valide ne prouve pas à elle seule qu’une archive exploitable est bien conservée. Le téléchargement peut échouer en cours de route ; un fichier peut être vide, mal classé ou associé au mauvais build. Il faut donc séparer la réception technique du contrôle de qualité.

Utilisez cette liste de vérification dans votre tâche manuelle ou automatisée :

• [ ] Le build et l’action correspondent au commit ou à la branche attendus.
• [ ] Le nom et le type de chaque fichier téléchargé correspondent à ceux annoncés par l’API ou le rapport.
• [ ] Le transfert s’est terminé sans erreur et la copie finale se trouve dans l’espace d’archive prévu.
• [ ] Le fichier s’ouvre ou peut être inspecté par l’outil approprié à son format.
• [ ] Les journaux et les résultats de test sont associés au même build que l’archive ou les symboles concernés.
• [ ] Le chemin de stockage, l’identifiant du build et le statut de vérification sont consignés.
• [ ] Les secrets, jetons et éléments de signature sont absents des journaux d’exécution et des fichiers partagés.
• [ ] Les droits d’accès sont accordés aux seules personnes ou automatisations qui en ont besoin.
• [ ] La procédure de reprise est connue si le téléchargement échoue ou si un artefact attendu n’est plus disponible.

Pour les fichiers qui s’y prêtent, l’équipe peut calculer une empreinte locale au moment de l’archivage afin de détecter une modification ultérieure de sa copie. Cette empreinte ne prouve pas, à elle seule, que le fichier reçu est identique à une valeur de référence fournie par Apple. Elle sert à vérifier la stabilité de la copie conservée, pas à remplacer la comparaison avec le build et le type attendus.

Les journaux méritent une vérification particulière. Ils peuvent contenir des chemins locaux, des paramètres de compilation ou des détails sur l’architecture du projet. N’intégrez pas automatiquement les journaux complets à un espace accessible à tous les utilisateurs du dépôt. Si vous transmettez une archive à un prestataire ou à une autre équipe, appliquez la procédure de partage et de nettoyage des informations internes de votre organisation.

Fixer une rétention interne et tester le parcours réel

La disponibilité annoncée par Apple et la rétention décidée par votre équipe sont deux sujets différents. Apple documente une période d’accès maximale de 30 jours aux informations de build et aux artefacts Xcode Cloud ; l’équipe doit déterminer séparément quels fichiers conserver, dans quel espace, avec quels droits et selon quelles règles de suppression. Ne présentez pas la limite côté Apple comme la durée de rétention garantie par votre propre stockage.

Choisissez la rétention à partir des besoins de publication, de diagnostic, de conformité et de capacité de restauration. Les archives nécessaires à l’analyse d’un crash n’ont pas nécessairement le même cycle de vie que les rapports de tests temporaires. Définissez aussi le responsable du nettoyage et la manière de traiter les builds remplacés, les branches abandonnées et les demandes d’effacement. Sans responsable, les copies s’accumulent ou disparaissent sans décision explicite.

Avant de généraliser le flux, faites-le fonctionner avec un build réel du projet. Vérifiez le parcours complet : authentification, repérage du build, récupération des artefacts, téléchargement, ouverture des fichiers, classement et consultation par une personne habilitée. Testez également le cas d’échec : adresse expirée, accès refusé, fichier absent ou transfert incomplet. La procédure doit produire un statut compréhensible et permettre une nouvelle tentative sans créer de doublons impossibles à distinguer.

Si le contrôle exige Xcode ou un autre outil exclusivement disponible sous macOS, exécutez cette validation dans un environnement Mac approprié. En revanche, le simple transfert et le classement des fichiers ne justifient pas toujours un Mac : une tâche d’automatisation déjà sécurisée peut suffire si elle respecte les exigences de l’équipe. Pour les opérations qui nécessitent un poste macOS accessible à distance, consultez les informations d’accès dans notre centre d’aide avant de décider où placer cette étape.

Questions fréquentes

Les réponses ci-dessous distinguent la disponibilité des fichiers hébergés par Apple, la récupération via API et la conservation dans l’espace choisi par l’équipe. Cette distinction évite de confondre un lien de téléchargement temporaire avec une archive exploitable à long terme.

Si votre processus actuel consiste à télécharger manuellement depuis l’interface, il reste adapté à une revue ponctuelle, mais dépend d’un opérateur, d’un poste et d’un rangement cohérent. L’automatisation réduit cette dépendance seulement si elle inclut les contrôles, la protection des clés et une politique de conservation ; elle ne les remplace pas.

Pour les équipes qui doivent aussi ouvrir un projet, inspecter une archive ou exécuter un outil de validation propre à macOS, un Mac distant peut compléter l’archivage sans transformer l’API en dépendance à une machine précise. À l’inverse, si le travail est durable, lourd et exige des interfaces physiques locales, l’achat d’un Mac peut être plus approprié. Lorsque l’usage est temporaire ou lié à un projet, comparez les formules de location Mac de metalvnc à votre besoin réel avant de déplacer une étape de CI ; le choix du stockage et des accès doit rester indépendant de ce choix de calcul.

Questions fréquentes