Ce guide s’adresse aux développeurs et ingénieurs CI/CD qui utilisent Oakmini pour la première fois. Choisissez un Mac mini physique dédié, connectez-vous en SSH ou VNC, restaurez l’outillage Apple Silicon, réalisez un build reproductible et intégrez un self-hosted runner à votre pipeline.
$ uname -m
arm64
$ sw_vers -productVersion
macOS ready
$ system_profiler SPHardwareDataType
Chip: Apple M4
$ xcodebuild -version
Xcode toolchain detected
$ git --version
git ready
✓ baseline de l’environnement enregistréeClarifiez la compatibilité, la région, la durée et les autorisations avant la connexion afin d’éviter les incompatibilités d’architecture, le manque d’espace disque ou les droits insuffisants sur le dépôt. Conservez les résultats dans le journal de migration du projet.
Vérifiez que les dépendances proposent une version arm64 , en contrôlant notamment les outils binaires, images de conteneurs, extensions natives et anciens scripts. Si le projet vient d’un environnement Intel, listez d’abord les composants à remplacer ou à recompiler.
file ./your-binaryConfirmer l’architecture cibleChoisissez Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong ou l’ouest des États-Unis. Pour VNC, privilégiez la proximité des opérateurs ; pour les builds automatisés, tenez compte du dépôt, du stockage des artefacts et de l’équipe.
ping / tracerouteMesurer depuis le réseau professionnelLa journée convient aux validations courtes, la semaine aux migrations intensives, et le mois ou le trimestre au développement continu et au runner permanent. Estimez toute la durée, de la préparation à l’export des artefacts, plutôt que le seul temps d’exécution.
day / week / month / quarterNe mélangez pas les durées de commandeEstimez séparément le dépôt, le cache des dépendances, les données de simulateur, les archives et les artefacts exportés. Gardez une marge dans le répertoire de build pour éviter les interruptions dues au manque d’espace et définissez une stratégie de nettoyage du cache.
df -hRevérifier après la connexionPour les tâches en ligne de commande, préparez un client SSH et une clé ; pour l’interface graphique macOS, préparez un client VNC. Vérifiez les connexions autorisées par votre réseau local et notez l’impact du pare-feu, du proxy ou du VPN de l’entreprise.
ssh -VVérifier d’abord le client localVérifiez les droits nécessaires pour lire le dépôt, accéder aux sources de dépendances, enregistrer le runner CI, utiliser les éléments de signature et téléverser les artefacts. Privilégiez des identifiants dédiés avec les autorisations minimales.
read / build / uploadDétailler le périmètre des droitsOak Core et Oak Forge sont des Mac mini physiques dédiés, et non des machines virtuelles. Basez votre choix sur la mémoire maximale, le nombre de builds parallèles, la taille du jeu de travail et le volume des artefacts, pas sur des multiplicateurs de performance vagues.
Convient au débogage d’un projet, à la validation des dépendances, aux tâches automatisées peu concurrentes et aux contrôles de migration courts. Ajoutez du stockage si le dépôt, les simulateurs et les archives sont volumineux.
Convient aux projets parallèles, graphes de dépendances volumineux, compilations gourmandes en mémoire, expériences d’inférence IA Apple Silicon et tâches nécessitant de nombreux caches et artefacts.
| Champ de commande | Options | Critère de choix | Résultat attendu |
|---|---|---|---|
| Durée de facturation | Jour, semaine, mois, trimestre | Couvre la préparation, l’exécution, la validation et l’export des artefacts | Les dates de début et de fin affichées correspondent au plan |
| Nœud | Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong, ouest des États-Unis | Chemin réseau réel entre les utilisateurs, le dépôt et la cible des artefacts | La région correspond à la baseline |
| Extension du stockage | +1TB SSD ou +2TB SSD | Volume total du dépôt, des caches, du répertoire de travail, des archives et des artefacts | Prévoir de l’espace pour le nettoyage et les fichiers temporaires |
| Option de mise en parallèle | Mise en parallèle Thunderbolt 5 (par machine) | À sélectionner uniquement dans un workflow multi-nœuds planifié | Vérifier séparément quantité et topologie |
Lisez dans le portail l’état actuel de l’hôte, son adresse, son port et les indications d’identification. Ne devinez pas les paramètres à partir d’une ancienne commande ou de l’historique local. Utilisez SSH pour la ligne de commande et VNC pour l’interface graphique.
ssh -p <PORT> <USER>@<HOST>
hostname
sw_vers
uname -m
system_profiler SPHardwareDataType
df -h
systemsetup -gettimezone
dateEnregistrez la sortie dans le journal de migration. Elle doit au minimum confirmer le nom d’hôte, la version de macOS, l’architecturearm64 , le modèle de puce, la capacité disque, le fuseau horaire et l’heure actuelle.
L’hôte doit être prêt à accepter une connexion. Si son état évolue encore, attendez la mise à jour du portail au lieu de réessayer continuellement les identifiants.
Vérifiez l’adresse de l’hôte, le port, le nom d’utilisateur et le mode de connexion. Conservez le fichier de clé uniquement sur un appareil contrôlé.
Lors de la première connexion SSH, enregistrez l’empreinte. Si elle change de manière inattendue, interrompez la connexion et vérifiez-la via un ticket dans la console.
Avec VNC, choisissez d’abord une résolution et une qualité adaptées au réseau, puis vérifiez la disposition du clavier, le presse-papiers et les réglages de veille.
Établissez d’abord un environnement de base vérifiable, puis installez les dépendances du projet. Ne copiez pas tout le répertoire utilisateur de l’ancienne machine ; migrez plutôt l’inventaire, la configuration et les fichiers de verrouillage afin de limiter les écarts d’architecture et les caches inutiles.
Restaurez l’inventaire logiciel, lancez le diagnostic et vérifiez le préfixe d’installation ainsi que l’environnement shell. Les chemins courants d’Apple Silicon doivent correspondre aux chemins codés dans les scripts ou être adaptés.
brew bundle check && brew doctorConfigurez l’identité de commit, la gestion des fins de ligne et l’accès aux identifiants. Clonez d’abord un dépôt de test en lecture seule pour vérifier le réseau et les droits avant de traiter le projet de production.
git config --list --show-originRestaurez Ruby, Node.js, Python et les autres versions indiquées par les fichiers de verrouillage. Notez le gestionnaire de versions, les outils globaux et les versions du projet ; ne vous fiez pas à la mention « dernière version ».
ruby -v; node -v; python3 --versionVérifiez le répertoire développeur sélectionné, la version de Xcode, le SDK et les outils en ligne de commande. Si plusieurs projets utilisent des versions différentes, documentez explicitement le changement dans le pipeline.
xcode-select -p; xcodebuild -versionRestaurez les dépendances avec le fichier de verrouillage du dépôt et conservez le journal complet de résolution. Si une dépendance compile une extension native, vérifiez que l’architecture de sortie est arm64.
file ./path/to/native-extensiondate
hostname
sw_vers
uname -m
xcode-select -p
xcodebuild -version
git --version
brew --version
brew list --versions
ruby -v
node -v
python3 --version
df -hLe premier build vise à confirmer la reproductibilité de la résolution des dépendances, des droits de signature, des répertoires de sortie et des journaux, pas à réduire le temps d’exécution. Testez d’abord un commit fixe, puis élargissez au projet complet.
Récupérez le commit ou le tag indiqué et vérifiez les sous-modules, dépendances privées et objets volumineux. Notez le hash du commit afin que les entrées restent inchangées pendant le test.
git rev-parse HEAD
Restaurez les dépendances avec le fichier de verrouillage et écrivez la sortie standard et les erreurs dans le journal. En cas de problème d’architecture, identifiez d’abord le binaire concerné au lieu de vider tout l’environnement.
command 2>&1 | tee dependency.log
Vérifiez que le processus de build peut lire les éléments de signature et les fichiers de configuration requis. Le compte automatisé ne doit disposer que des droits nécessaires au projet et aux étapes de build.
security find-identity -v -p codesigning
Placez DerivedData, les archives, les résultats de test et les artefacts exportés dans des répertoires explicites, sans partager de chemins temporaires non contrôlés.
mkdir -p build logs artifacts
Les journaux doivent au minimum contenir le commit, la version de Xcode, le SDK, la commande, les heures de début et de fin ainsi que le code de sortie. Anonymisez les données sensibles avant l’envoi.
echo "$?" > logs/exit-code.txt
Relancez avec le même commit et la même configuration pour vérifier que les dépendances, chemins et droits ne dépendent pas d’actions temporaires de la première session. Les deux résultats doivent être comparables et explicables.
./scripts/verify-build.sh
xcodebuild \
-project Example.xcodeproj \
-scheme Example \
-configuration Release \
-derivedDataPath ./build/DerivedData \
build 2>&1 | tee ./logs/first-build.logLe code de sortie est 0 ; le journal permet d’identifier le commit et l’outillage fixes ; le répertoire de sortie contient les artefacts attendus ; une nouvelle exécution ne dépend d’aucune action manuelle non documentée.
Les trois flux peuvent être préparés en parallèle, mais doivent converger sur une même baseline : version fixe du dépôt, versions de l’outillage, étiquettes du runner, puis déclenchement d’une tâche de validation reproductible.
Ne migrez que les données explicables ; ne transférez pas les états historiques impossibles à retracer.
Restaurez les outils depuis l’inventaire et confirmez le résultat avec leurs versions.
Faites correspondre explicitement les règles de planification à ce Mac physique dédié.
Un environnement fonctionnel n’est pas forcément prêt pour un usage durable. Après le premier build, traitez immédiatement les identifiants initiaux, le stockage des clés, le périmètre du dépôt et les informations sensibles présentes dans les scripts.
Avant chaque commit, recherchez les champs sensibles et vérifiez l’historique shell, les fichiers d’environnement, la configuration CI et les journaux. Révoquez et remplacez tout identifiant exposé avant de nettoyer l’historique des fichiers.
Limitez les permissions des clés privées, supprimez les clés publiques inutilisées et documentez le nom et l’usage des clés d’automatisation.
chmod 600 ~/.ssh/private_key
Conservez les heures, commandes, versions, codes de sortie et traces d’erreur ; supprimez les jetons d’accès, contenus de clés privées, éléments de signature et autres informations directement utilisables pour l’autorisation.
La validation doit reposer sur des résultats reproductibles, et non sur le fait que « cela fonctionne maintenant ». Déconnectez-vous, reconnectez-vous et relancez les commandes clés depuis un shell propre.
Déconnectez activement SSH et VNC, puis reconnectez-vous avec les paramètres enregistrés. L’empreinte de l’hôte, le nom d’utilisateur, le port et la session graphique doivent correspondre aux informations consignées.
Restaurez les dépendances avec le fichier de verrouillage ; le code de sortie est 0 ; l’architecture des composants natifs est correcte ; le journal d’installation est conservé sans données sensibles.
Réalisez le build avec un commit et des versions d’outillage fixes. Le répertoire de sortie est explicite et la seconde exécution ne dépend d’aucune action manuelle non documentée.
Les archives, résultats de test et autres artefacts cibles sont exportables depuis le répertoire indiqué ; leurs noms, versions et méthodes de vérification respectent les conventions de l’équipe.
Le self-hosted runner est en ligne, ses étiquettes correspondent à la tâche cible et il n’accepte pas les travaux de projets non autorisés.
La baseline, les journaux de dépendances et de build, le code de sortie et les chemins d’artefacts sont archivés ; les champs sensibles sont anonymisés.
Vérifiez dans le portail l’état de l’hôte, les informations de commande et l’accès de gestion. Tous les nœuds fonctionnent normalement 365 jours par an.
Consultez les nœuds disponibles dans le portail et choisissez Oak Core ou Oak Forge, la durée de facturation et les options de stockage. Après la commande, suivez cette page pour la connexion, la restauration de l’outillage et la validation.