MiniDebug M4 est une machine physique dédiée : les ressources ne sont pas partagées avec d’autres commandes. Nous décomposons ci-dessous les entrées, étapes, sorties et échecs courants de tâches réelles pour vous aider à évaluer son adéquation à vos workflows iOS, CI, IA ou créatifs.
Un packaging automatisé fiable ne se résume pas à une commande. Il faut figer la version du code source, l’état des dépendances, la version de Xcode, les paramètres de signature et d’export ainsi que la destination des artefacts, afin de localiser tout échec dans les journaux.
Entrée : Adresse du dépôt, branche, hash de commit, configuration de build et Scheme cible. Un webhook ou une tâche en file ne transmet que les identifiants ; le script ne doit pas deviner la branche à la volée.
Point d’échec : Commit inexistant, sous-modules non synchronisés, droits insuffisants ou lecture par la même tâche d’une tête de branche en évolution.
Entrée : Package.resolved, Podfile.lock ou autre fichier de verrouillage. La clé de cache doit au minimum inclure le résumé du verrouillage des dépendances, la version de Xcode et l’architecture cible.
Point d’échec : Dérive du fichier de verrouillage, cache incompatible avec la chaîne d’outils, identifiants de dépendances privées expirés ou espace disque insuffisant.
Entrée : Chemin du Workspace ou du Project, Scheme, Configuration, Destination et chemin d’archive. Affichez d’abord la version des outils, puis lancez l’archivage.
Point d’échec : Erreur de compilation, échec des tests, incompatibilité de la version cible, DerivedData pollué ou script de build dépendant d’un chemin absolu local.
Entrée : Certificats, profils de provisioning et variables d’environnement nécessaires, avec les permissions minimales. Injectez ces éléments au début de la tâche et supprimez-les à la fin.
Point d’échec : Certificat et profil incompatibles, périmètre de permissions incorrect, problème de validité ou utilisation par erreur du même trousseau temporaire par plusieurs tâches.
Entrée : Fichier d’archive et configuration ExportOptions. Après l’export, consignez le nom, la taille, le résumé de contrôle et l’heure de génération, au lieu de vérifier seulement l’existence du répertoire.
Point d’échec : Méthode d’export incompatible avec la configuration de signature, droits insuffisants sur le répertoire de sortie ou code de sortie non nul ignoré par le script.
Sortie : Artefacts de build, fichier d’archive, rapport de tests, journaux de build, hash de commit et identifiant de tâche. Nettoyez le répertoire de travail uniquement après confirmation de la réussite du téléversement.
Point d’échec : Interruption du téléversement, collision de noms d’artefacts, champs sensibles dans les journaux ou nettoyage effectué avant confirmation du résultat.
L’objectif d’une ferme de build n’est pas seulement d’exécuter les tâches simultanément, mais de rendre explicites la file, les étiquettes des nœuds, les limites du cache et le retour des résultats. Un MiniDebug M4 peut héberger un canal d’exécution contrôlé ; les tâches supplémentaires doivent être réparties sur les nœuds physiques associés à d’autres commandes.
Le cache des dépendances peut être réutilisé selon le résumé du fichier de verrouillage, la version de Xcode et l’architecture. DerivedData, les trousseaux temporaires, les répertoires d’export et les modifications non validées ne doivent pas être réutilisés directement entre dépôts.
La mise en file, l’exécution, le téléversement et la fin sont des états d’ordonnancement ; compilation réussie, tests échoués et signature échouée sont des résultats de tâche. Les consigner séparément permet de distinguer un problème de capacité d’un problème de projet.
L’enregistrement du Runner n’est qu’une étape d’intégration. La stabilité dépend surtout de la précision des étiquettes, du contrôle de la concurrence sur la machine, du nettoyage en fin de tâche et de la capacité à rattacher les journaux d’échec à l’exécution correspondante.
Conservez les étiquettes système et ajoutez des étiquettes de capacités maintenables à long terme, par exemple macos , arm64 , xcode-current et signing-ready. N’inscrivez pas le nom d’un projet temporaire ou d’une branche éphémère dans les étiquettes du nœud.
runs-on:
- self-hosted
- macos
- arm64
- xcode-currentAvant l’enregistrement, vérifiez le périmètre du Runner, les limites d’accès au dépôt et le répertoire de travail. Le compte d’exécution ne reçoit que les permissions nécessaires au build ; il ne doit pas servir aux opérations distantes quotidiennes ni contenir de secrets persistants directement dans les scripts.
Ne lancez jamais simultanément deux tâches d’écriture dans le même répertoire de travail. Avant chaque tâche, vérifiez les processus résiduels et l’espace disque ; après la tâche, supprimez la copie du code source, les fichiers d’export temporaires, le trousseau temporaire et les variables d’environnement propres au projet.
Si la concurrence est nécessaire, répartissez les tâches sur des nœuds physiques distincts au lieu de laisser signature, archivage et nettoyage s’écraser dans le même répertoire.
L’étape de collecte des journaux doit continuer après un échec et renvoyer au minimum la sortie de xcodebuild, les résultats de tests, l’espace disque disponible, les versions d’outils et l’identifiant de tâche. Supprimez les jetons, clés privées, mots de passe de certificats et variables sensibles du dépôt avant le téléversement.
Distinguez Runner hors ligne, délai dépassé, sortie du script et échec du téléversement des artefacts, afin que tous les problèmes ne soient pas réduits à « build échoué ».
Les développeurs indépendants n’ont généralement pas besoin d’automatiser toutes les étapes d’un coup. Il est plus fiable de définir clairement le passage entre opérations graphiques et tâches en ligne de commande, afin de pouvoir revenir en arrière lors des corrections, validations, archivages et préparations des artefacts avant TestFlight.
Terminez les modifications, les tests de base et le commit, poussez une branche figée et notez les conditions de l’appareil à vérifier ainsi que les résultats attendus.
Sortie : hash du commit, description des changements, périmètre des testsVérifiez le Scheme, la version cible et les réglages du projet, traitez les avertissements nécessitant un jugement visuel et confirmez que la signature couvre précisément cette publication.
Sortie : état du projet et paramètres de publication validésExécutez l’archivage, l’export et la vérification sous forme de scripts, en conservant les journaux complets. En cas de problème, revenez aux entrées correspondantes plutôt que de modifier manuellement un état inconnu sur la machine en échec.
Sortie : fichier d’archive, paquet exporté, résumé de contrôleL’interface graphique sert uniquement aux réglages et vérifications nécessitant un jugement humain ; confiez l’archivage, l’export, les nouvelles tentatives et le nommage des artefacts aux scripts. Après chaque modification manuelle, validez le changement du projet ou consignez la différence pour préserver la reproductibilité du build suivant.
MiniDebug M4 est équipé d’un M4, de 16 Go de RAM et d’un SSD de 256 Go. Commencez par vérifier que le modèle et les données respectent ces ressources, puis mesurez le chargement, la mémoire, l’inférence prolongée et la qualité des sorties sans mélanger des résultats obtenus avec des paramètres différents.
Consignez le format du modèle, la version de quantification, la version du runtime, le hash du commit, les échantillons d’entrée et les paramètres aléatoires. Identifiez les fichiers du modèle par leur résumé de contrôle afin d’éviter que des fichiers de même nom aient un contenu différent.
Le premier chargement inclut la lecture et l’initialisation du modèle ; il ne doit pas être combiné à la phase de fonctionnement stable. Utilisez pour chaque série la même longueur d’entrée, la même taille de lot, le même nombre de répétitions et les mêmes paramètres d’échantillonnage.
La quantification ne se compare pas uniquement sur la vitesse. Conservez aussi les sorties produites avec les mêmes entrées, l’évaluation de la qualité, les échantillons erronés et les informations d’environnement, puis exportez des résultats lisibles par machine et des conclusions humaines.
{
"machine": "MiniDebug M4 / M4 / 16GB / 256GB",
"model_variant": "project-defined",
"input_set": "fixed-evaluation-set",
"measurements": [
"load_time",
"first_output_time",
"total_time",
"peak_memory"
],
"artifacts": ["result.csv", "runtime.log", "notes.md"]
}Les goulots d’étranglement audio-vidéo peuvent venir du transfert des médias, de la compatibilité des extensions, de l’affichage distant, de la capacité disque ou des paramètres d’export. Séparez ces étapes pour ne pas confondre une connexion saccadée avec un problème de calcul de l’hôte.
Générez d’abord un inventaire des médias avec le nombre de fichiers, leur taille totale, l’arborescence et les résumés de contrôle. Ne synchronisez que les proxies ou sources nécessaires à l’étape en cours, puis vérifiez les éléments manquants.
Point de contrôle : Le chemin du projet ne doit pas dépendre d’une lettre de lecteur locale ; les références média doivent pouvoir être relocalisées et le SSD de base de 256 Go doit conserver de l’espace pour le cache du projet et l’export.
Ouvrez le projet via une connexion graphique et vérifiez les polices, extensions, liens média, paramètres d’échantillonnage et cibles de sortie. Sur un réseau faible, réduisez d’abord la qualité et la résolution de l’affichage distant, sans modifier les paramètres d’export du projet.
Point de contrôle : Distinguez la qualité de l’aperçu distant de celle du fichier final ; si une extension manque, arrêtez d’abord les tâches par lots afin d’éviter de produire des résultats incomplets.
Figez le préréglage d’export, le nommage et le répertoire cible, puis exécutez la liste des tâches. Pour chaque tâche, conservez l’état de sortie, la durée, la taille produite et les erreurs.
Point de contrôle : Vérifiez l’espace disque avant toute tâche longue ; validez progressivement le niveau de parallélisme selon la mémoire, la lecture des médias et la charge d’encodage.
Contrôlez par échantillonnage l’image, les pistes audio, la durée, la résolution et les en-têtes de fichiers, puis générez un résumé de contrôle. Après confirmation de la réception complète en local, supprimez les fichiers temporaires du cloud.
Sortie : Fichiers finaux, journaux d’export, liste des échecs, résumé de contrôle et preuve de réception locale.
Le choix du nœud ne dépend pas seulement du lieu de votre équipe. Tenez aussi compte du dépôt de code, des sources de dépendances, de l’opérateur distant et de la destination finale. Ces indications orientent le choix sans garantir un résultat réseau fixe ; les performances réelles dépendent du réseau local et des liaisons interrégionales.
| Nœud | Emplacement d’équipe à privilégier | Emplacement du dépôt et des dépendances | Destination habituelle des livrables | À vérifier avant la commande |
|---|---|---|---|---|
| Singapour | Équipes d’Asie du Sud-Est ou collaborateurs répartis dans la région | À tester en priorité lorsque les dépôts, artefacts ou services de dépendances sont principalement situés en Asie du Sud-Est | Builds quotidiens, développement distant et retour des résultats pour les équipes d’Asie du Sud-Est | Tester le clonage du dépôt, le téléchargement des dépendances et la connexion graphique distante |
| Japon (Tokyo) | Équipes du Japon et de l’Asie de l’Est voisine | À tester en priorité lorsque les chemins d’accès au code et aux dépendances sont proches du Japon | Builds iOS, vérifications de signature et opérations Xcode à distance pour les équipes japonaises | Vérifier la stabilité interactive locale et l’envoi de fichiers volumineux |
| Corée du Sud (Séoul) | Équipes de Corée du Sud et d’Asie du Nord-Est | À envisager lorsque l’accès aux dépôts et ressources internes est plus direct depuis la Corée du Sud | Intégration continue, Runner auto-hébergé et distribution régionale des artefacts | Vérifier la reconnexion du Runner, l’accès aux dépendances et l’envoi des journaux |
| Hong Kong | Équipes collaborant entre la Chine du Sud et l’Asie du Sud-Est | À comparer en priorité lorsque le code, les médias et les opérateurs sont répartis entre la Chine du Sud et l’Asie du Sud-Est | Collaboration interrégionale, tâches graphiques distantes et traitement des médias | Tester séparément les chemins depuis le réseau professionnel et le réseau domestique |
| Côte Est des États-Unis | Équipes de la côte Est de l’Amérique du Nord et collaborant avec l’Europe occidentale | À envisager lorsque le dépôt, le plan de contrôle CI ou le système de livraison se trouve principalement sur la côte Est | Files de build, retour des résultats et contrôles collaboratifs pendant les heures ouvrées nord-américaines | Tester les trois chemins : dépôt, stockage des artefacts et opérateur distant |
Les extraits ci-dessous servent de structure de script et ne constituent pas une configuration complète utilisable pour tous les projets. Avant de les enregistrer dans le dépôt, vérifiez le Workspace, le Scheme, la version de Xcode, la configuration d’export, les éléments de signature, les étiquettes du Runner et le répertoire des artefacts selon le type de projet.
set -euo pipefail
PROJECT_ROOT="/path/to/project"
WORKSPACE="$PROJECT_ROOT/Example.xcworkspace"
SCHEME="Example"
ARCHIVE_PATH="$PROJECT_ROOT/output/Example.xcarchive"
xcodebuild -version
xcodebuild \
-workspace "$WORKSPACE" \
-scheme "$SCHEME" \
-configuration Release \
-destination "generic/platform=iOS" \
-archivePath "$ARCHIVE_PATH" \
clean archiveRemplacez le chemin du projet, le Workspace, le Scheme, la Configuration, la Destination et le répertoire d’archive. Le script doit conserver les codes de sortie non nuls et vérifier la version de Xcode requise avant l’exécution.
lane :build_release do
setup_ci
build_app(
workspace: "Example.xcworkspace",
scheme: "Example",
configuration: "Release",
output_directory: "output"
)
sh("shasum -a 256 output/*")
endRemplacez le Workspace, le Scheme, le répertoire de sortie et les paramètres d’export selon le projet. Fournissez les éléments de signature via des variables contrôlées ou une injection au niveau de la tâche ; ne les écrivez pas directement dans le Fastfile.
name: ios-build
on:
workflow_dispatch:
jobs:
archive:
runs-on:
- self-hosted
- macos
- arm64
- xcode-current
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Build
run: ./scripts/archive.sh
- name: Collect diagnostics
if: always()
run: ./scripts/collect-diagnostics.shAdaptez les étiquettes réelles du Runner, les règles du dépôt et le chemin des scripts. Figez les versions des actions utilisées, définissez un délai maximal et laissez la collecte des diagnostics continuer en cas d’échec du build.
Commencez par un commit figé, une exécution unique, l’archivage des journaux et la vérification des artefacts, puis ajoutez progressivement le cache, l’injection de signature et l’ordonnancement en file. Location à la journée, à la semaine, au mois ou au trimestre ; les commandes sont réglées en dollars américains (USD).
Le paiement est limité à USDT-TRC20 et Visa / Mastercard / Amex (via Stripe). Les moyens réellement disponibles sont ceux renvoyés par le portail.