2026 : accélérer Cargo sur Mac distant — miroirs, retry et lockfile

• 1

  Latence et jitter : de longues chaînes TLS vers index.crates.io et les CDN de crates multiplient les allers-retours ; un simple cargo build devient sensible aux coupures transitoires.

• 2

  Lockfile ignoré ou divergent : sans --locked, la CI peut résoudre des versions différentes du poste développeur, ce qui masque les vrais problèmes réseau et casse la reproductibilité.

• 3

  Proxy et inspection TLS : les environnements filtrés exigent des racines de confiance ou des variables proxy cohérentes ; sinon Cargo échoue avant même le téléchargement des artefacts.

Choisissez une ligne selon votre contrainte dominante ; la colonne lockfile rappelle l’engagement équipe à tenir entre machine locale, runners CI et éventuels miroirs privés.

En pratique, un fichier .cargo/config.toml au dépôt peut rediriger crates-io vers une source nommée ; l’exemple suivant illustre le schéma « replace-with » sans imposer un domaine unique, car votre miroir dépend de la politique réseau :

Remplacez la valeur registry par l’URL fournie par votre fournisseur (miroir académique, cloud interne, etc.) ; testez avec cargo fetch -v avant d’industrialiser la CI.

Le principe est d’isoler résolution, téléchargement et compilation afin de mesurer où le temps disparaît ; sur un runner macOS distant, exportez les variables une seule fois par job.

Étape 1 — aligner l’index : copier .cargo/config.toml dans le dépôt et valider cargo metadata --locked localement.

Étape 2 — pré-tirage : dans le pipeline, exécuter cargo fetch --locked (ou workspace équivalent) avant cargo build --locked pour séparer les erreurs réseau des erreurs de compilation.

Étape 3 — cache ciblé : persister ~/.cargo/registry et target si votre orchestrateur le permet ; invalider lors d’un changement de checksum du lockfile.

Étape 4 — secret proxy : injecter HTTP_PROXY, HTTPS_PROXY et éventuellement NO_PROXY pour les hôtes internes ; évitez de logger les URLs complètes.

Étape 5 — contrôle lockfile : pour une application, échouer le job si cargo build --locked demande une mise à jour du lock ; ouvrez une PR dédiée pour toute régénération.

Exemple minimal d’en-tête de job (shell) mélangeant retry et build verrouillé :

Timeouts : au-delà de CARGO_HTTP_TIMEOUT, vérifiez le MTU et la stabilité VPN ; un traceroute vers l’hôte du registre aide à distinguer perte de paquets et saturation.

Certificats : si une appliance SSL déchiffre le trafic, installez sa CA dans le trousseau macOS ou définissez CURL_CA_BUNDLE vers un fichier PEM agrégé ; sans cela, Cargo hérite des échecs de libcurl.

Proxy : alignez les variables minuscules et majuscules attendues par curl ; pour les scripts internes, préférez un proxy explicite plutôt que des redirections transparentes non documentées.

Résumé opérationnel : combinez retries modérés, timeout large et miroir géographiquement logique ; mesurez le gain avec cargo fetch seul pour ne pas mélanger compilation et réseau.

Dans un monorepo Cargo, un seul Cargo.lock à la racine simplifie la CI ; les crates internes en path ne passent pas par crates.io mais les dépendances externes restent soumises au registre choisi.

Avec des sous-modules Git contenant leurs propres crates, fixez une règle claire : soit chaque sous-arbre possède son lock et son job dédié, soit vous normalisez un workspace parent — mélanger les deux sans documentation crée des doubles résolutions et des caches invalides.

Lorsque le sous-module pointe vers une révision précise, exécutez cargo build --locked dans chaque crate publiable avant fusion ; pour l’accueil produit et les offres sans compte, la page d’accueil MacPull résume l’accès aux machines ; les tarifs détaillent les formules.