Scénarios et irritants
En 2026, beaucoup de dépôts combinent le préfixe jsr: (registre JSR, métadonnées sur jsr.io) et la compatibilité npm (npm: ou champs npm dans deno.json), souvent relayés par un proxy d’entreprise ou un miroir interne. Sur un runner macOS loué, le problème n’est presque jamais le CPU : c’est le volume de petites requêtes HTTP, les tarballs occasionnellement lourds, et la concurrence entre plusieurs pipelines qui saturent la même sortie WAN.
Sans deno.lock versionné et sans sous-répertoire de cache dédié par job, vous observez des symptômes « flakys » : résolution qui diverge, cache partiellement incohérent après changement de miroir, ou échecs TLS intermittents masqués par des retries trop agressifs. La table suivante tranche entre stratégies — pas pour élire un « gagnant » unique, mais pour allouer la complexité au bon endroit.
| Contrainte | Stratégie préférable | Risque principal sur Mac distant |
|---|---|---|
| Code majoritairement sur JSR, build reproductible exigé | Deno + deno.lock + étape CI frozen |
Lock absent ou non gelé → mises à jour transitives silencieuses |
| Beaucoup de paquets npm historiques | Chemin npm explicite + migration progressive vers jsr: |
Même DENO_DIR partagé entre politiques de registre différentes |
| Plusieurs équipes sur un seul hôte | Préfixe DENO_DIR par tenant/pipeline + quotas de jobs parallèles |
Tempête de deno cache au démarrage froid |
Deno/JSR : tableau des chemins de tirage
Le débogage transfrontalier commence par savoir quel hôte sert les métadonnées et où Deno range les artefacts. Les paquets jsr: et les dépendances npm ne partagent pas la même sémantique de cache ni les mêmes modèles d’auth — les traiter comme un seul « nuage npm » conduit à des règles NO_PROXY incomplètes et à des journaux illisibles.
| Axe | JSR (jsr:) | Chemin npm compatible |
|---|---|---|
| Origine typique | Métadonnées et artefacts via l’écosystème JSR / jsr.io |
Registry npm configuré (public, Nexus, Artifactory, etc.) |
| Déclaration | Préfixes et import maps dans deno.json |
Champs npm ou préfixe npm: selon votre setup |
| Auth privée | DENO_AUTH_TOKENS (hôte=jeton), jamais dans le dépôt Git |
Même variable ou jetons spécifiques au registry |
| Observabilité | Tracer 401/403 et chaînes de redirection vers jsr.io | Vérifier cohérence lock ↔ empreinte du registry |
Si la même machine tire aussi des dépôts Git et des images OCI, alignez la politique de sortie : un seul schéma HTTPS_PROXY / NO_PROXY documenté évite que seul npm passe par le chemin optimisé pendant que jsr.io reste sur un trajet saturé. Le guide miroirs Git / npm / Homebrew transfrontaliers détaille cette coordination au niveau org.
Lockfile et répertoire de cache : paramètres exécutables
Les lignes ci-dessous sont pensées pour être copiées dans un prélude shell (GitLab CI, Jenkins, Actions self-hosted, Buildkite, etc.) sur un Mac distant. L’idée fixe : un pipeline = un racine de cache, et le lock figé avant toute optimisation de débit.
| But | Variable / fichier | Exemple Mac distant |
|---|---|---|
| Racine de cache isolée | DENO_DIR |
$HOME/.cache/deno-ci-${CI_PIPELINE_ID:-local} |
| Reproductibilité | deno.lock |
Versionné ; CI : deno install --frozen ou deno cache --frozen … |
| Chaîne TLS entreprise | DENO_TLS_CA_STORE, SSL_CERT_FILE |
system ou bundle PEM agrégé ; valider avec un deno eval minimal |
| Sortie mandatée | HTTPS_PROXY, NO_PROXY |
Inclure registres internes et 127.0.0.1 dans NO_PROXY |
| Registres privés | DENO_AUTH_TOKENS |
registry.example.com=TOKEN injecté par le coffre de secrets |
- P0 —
deno.locken repo + mode frozen en CI : sans cela, ajuster la concurrence ne fait que déplacer le chaos. - P1 —
DENO_DIRpar job/pipeline ; clé d’artefact = hash du lock + version mineure de Deno + hôtes de registre. - P2 —
deno test --parallelet matrices : n’augmentez le parallélisme qu’après stabilisation réseau et disque.
Parallélisme CI et seuils de timeout
Sur un Mac loué partagé, l’erreur classique est de reproduire les réglages d’un laptop rapide : trois pipelines lancent chacun un deno cache froid au même instant, saturant le proxy et déclenchant des centaines de retries corrélés. Il faut séparer trois niveaux : l’orchestrateur (nombre de jobs simultanés), la commande Deno (tests parallèles), et les timeouts par étape.
| Niveau | Levier | Point de départ (Mac partagé) | Commentaire |
|---|---|---|---|
| Orchestration | max-parallel / files d’attente |
1–2 | Élever après constat de cache chaud et marge disque |
| Tests | deno test --parallel |
Activé si CPU le permet | Coupler à la limite d’orchestration pour éviter le flaky |
| Étape cache | Timeout du job (minutes) | 15–30 | Premier tirage transfrontalier souvent plus long que le LAN |
| Pipeline | Retry ciblé sur deno cache uniquement |
2–3 tentatives | Éviter de relancer tests + build complets à chaque timeout réseau |
Pour la capacité disque et la concurrence multi-outils (npm, Git, Homebrew), croisez avec la FAQ pool de builds : concurrence et disque — les mêmes seuils 80/85/90 % d’espace libre s’appliquent au répertoire qui héberge DENO_DIR.
FAQ — échecs réseau transfrontaliers et stratégie de retry
Faut-il vider tout le cache Deno du serveur après un échec ? Non : supprimez surtout le sous-répertoire du pipeline concerné. Une purge globale punit les autres équipes et masque la cause (proxy, certificat, lock non frozen).
Comment encapsuler deno install sans saturer la file d’attente CI ? Trois passages maximum avec attentes 2 s, 4 s, 8 s entre eux ; si le troisième échoue, sortie non nulle pour exposer l’erreur réseau dans le résumé du job. Ajoutez un léger jitter si plusieurs runners redémarrent en même temps.
TLS ou chaîne incomplète : par où commencer ? DENO_TLS_CA_STORE=system pour s’aligner sur le trousseau macOS ; si l’entreprise impose un PEM personnalisé, injectez-le via SSL_CERT_FILE et reproduisez avec une commande minimale avant la pipeline complète.
Pour des schémas de retry plus larges (npm, Homebrew, Git), voir FAQ stabilité des tirages Git, Homebrew et npm.
En synthèse : en 2026, fiabiliser Deno et JSR sur un Mac distant, c’est d’abord figer deno.lock et isoler DENO_DIR, puis seulement régler parallélisme et timeouts. La liaison transfrontalière se gouverne avec proxy, certificats et retries bornés — pas en « montant le débit » aveuglément. Pour un nœud Apple Silicon homogène avec votre poste de dev, une sortie réseau plus prévisible et des pages sans connexion obligatoire, consultez l’accueil, la page achat, les tarifs et le centre d’aide. Louer un Mac distant dédié aux pipelines permet de sortir les tirages lourds de votre laptop et d’appliquer une politique de cache et de concurrence commune à toute l’équipe.
Stabilisez les tirages, puis accélérez
MacPull propose des Mac mini cloud pour exécuter vos jobs Deno proches de vos utilisateurs. Tarifs, achat et aide restent consultables sans compte ; poursuivez la lecture sur le blog technique ou le guide miroirs transfrontaliers.