environment.yml : la route réseau vers les canaux (souvent transfrontalière), le choix entre conda, mamba et micromamba, puis le gel de la résolution décident si vos builds restent reproductibles. Ce guide propose une matrice décisionnelle, un modèle .condarc, des variables d’environnement et une checklist d’acceptation lockfile / manifeste. Navigation interne : accueil, liste du blog ; article connexe (autre chaîne d’artefacts sur runner Mac) : Nix Flake & substituters.
Matrice décisionnelle : conda, mamba, micromamba
En 2026, la plupart des équipes basculent le solve vers libmamba dans conda (conda install --solver=libmamba ou configuration par défaut Miniforge), ou utilisent directement mamba / micromamba pour réduire le temps CPU et clarifier le cycle de vie du binaire sur le runner.
| Outil | Forces | Limites | Cas Mac CI distant |
|---|---|---|---|
| conda (classique ou libmamba) | Écosystème mature, intégrations IDE, plugins. | Image plus lourde ; solve long si mal configuré. | Pipelines qui réutilisent déjà Miniforge/Miniconda et un seul CONDA_PKGS_DIRS partagé. |
| mamba | Résolution et téléchargements rapides, compatible avec les mêmes environment.yml. | Dépend d’une install conda de base. | CI avec gros graphes de dépendances ou mises à jour fréquentes du solve. |
| micromamba | Binaire autonome, préfixe explicite, idéal pour images « thin ». | Moins de magie historique ; discipline sur les chemins. | Runners éphémères ou multi-tenant où vous voulez un root court et des scripts reproductibles. |
Règle d’équipe : un seul outil par pipeline et un cache paquets documenté, sinon deux installations divergent sur les hashes même avec le même YAML.
Endpoints de miroir, alias de canaux et pulls transfrontaliers
Les canaux publics (conda-forge, defaults) sont souvent atteints depuis des POP éloignés ; un miroir d’entreprise ou un domaine régional réduit la latence et les coupures. Figez l’ordre des canaux : il change la résolution autant qu’une version manquante.
Sur chemins TLS inspectés, exportez SSL_CERT_FILE=/chemin/vers/entreprise.pem avant toute commande. Si le même pipeline tire aussi des images OCI, planifiez la fenêtre réseau pour ne pas superposer des rafales de pulls avec l’installation Conda.
conda config --show channelssur le runner = même liste qu’en préproduction.- Test
curl -Ivers lerepodata.jsondu miroir depuis le Mac (pas seulement depuis le bureau). - Journaliser l’URL effectivement utilisée lors du premier solve du jour (cold cache).
Paramètres d’installation parallèle et pression disque
Le parallélisme accélère les téléchargements mais multiplie les écritures dans pkgs et le préfixe environnement ; sur un Mac partagé, deux jobs lourds simultanés peuvent faire chuter les IOPS avant le linker.
Sur hôte multi-tenant : commencez par 2–4 téléchargements parallèles mesurés, montez seulement si iostat et la latence P95 restent stables. Isolez CONDA_PKGS_DIRS par équipe ou par pool si la politique de sécurité l’exige.
Si le disque approche des seuils documentés pour votre organisation, refusez les nouveaux jobs ou déclenchez un nettoyage de cache pkgs hors fenêtre critique, comme pour tout runner partagé.
Échecs réseau, timeouts et stratégie de retry
Les erreurs HTTP partielles ou les coupures transfrontalières laissent parfois des archives .conda ou .tar.bz2 incomplètes dans le cache ; un retry naïf réutilise le fichier corrompu. Combinez timeouts explicites, backoff et invalidation ciblée du cache en cas d’échec répété.
- Codes 502/503/504 ou reset TCP intermittents vers le miroir.
- Inspection TLS (proxy, inspection HTTPS) ajoutant de la latence.
- Après migration de canal : purge ciblée du sous-dossier
pkgsconcerné avant nouvel essai.
Lockfile, export et checklist de cohérence environment.yml
Un environment.yml seul ne fige pas toutes les versions transitives : deux semaines d’écart sur repodata suffisent à changer le graphe. Le pattern robuste est conda-lock (ou export explicite) pour la plateforme CI — ici typiquement osx-arm64.
- Manifeste :
name,channelsetdependenciesrelus ; pas de mélange involontaire pip/conda sans section dédiée. - Lock : fichier versionné ; build CI checkout le même commit de lock que la MR.
- Plateforme : entrée
osx-arm64présente si le runner est Apple Silicon ; pas seulementlinux-64. - Export : si vous utilisez
conda env export, préférez--from-historypour les specs humaines, ou acceptez le bruit des builds non reproductibles. - Non-régression : tests unitaires + binaire critique (ex. outil de signature) sur le préfixe créé depuis le lock.
Documentez dans le README du dépôt qui régénère le lock (rôle release manager ou bot) et quand refuser un merge si le diff lock dépasse un seuil de paquets.
FAQ — Conda sur Mac CI distant
Puis-je mélanger conda et micromamba sur le même host ?
Oui, mais séparez strictement CONDA_PKGS_DIRS et les préfixes ; sinon les caches mélangés rendent le diagnostic des incohérences très coûteux.
Le solve est identique mais le binaire diffère
Vérifiez la build string, le canal effectif et l’architecture (osx-arm64 vs osx-64). Un Rosetta mal configuré peut masquer l’écart jusqu’au runtime.
Que faire si le miroir interne est en retard sur conda-forge ?
Échouez tôt avec un message explicite ou épinglez une révision connue dans le lock ; ne combinez pas « dernier repodata public » et « miroir retardé » sans garde-fou.
Synthèse 2026 et prochain pas
En bref : choisir conda, mamba ou micromamba et s’y tenir → .condarc et miroirs alignés sur le runner → parallélisme et pkgs dimensionnés pour le SSD partagé → timeouts + retry avec backoff → conda-lock et checklist environment.yml. Pour louer un Mac cloud dédié aux pipelines : achat, tarifs, centre d’aide, accueil et liste du blog — pages consultables sans compte.
Mac cloud pour environnements Conda reproductibles
Pages ouvertes sans login : accueil, centre d’aide, achat, tarifs, blog technique (guides CI Mac 2026).