2026 CI Mac distant : artefacts OCI, cache à couches et matrice de tirage ORAS

Les pipelines qui assemblent plusieurs artefacts volumineux (modèles ML, archives de build, signatures Sigstore) subissent trois tensions sur un Mac distant : la latence WAN transfrontalière vers le registre, la concurrence des téléchargements qui déclenche des limites de débit, et le cache local qui remplit le SSD plus vite que les images conteneur — car les artefacts OCI portent souvent peu de couches réutilisables entre jobs. Sans digest figé, un tag mobile peut aussi glisser entre le pré-tirage et l’étape de test.

Étiquetez vos incidents 429, 5xx, TLS ou disque avant de monter ORAS_COPY_CONCURRENCY ou le parallélisme xargs -P : augmenter les deux en même temps reproduit les symptômes d’« essaim » qui coûtent cher sur un pool partagé.

ORAS (OCI Registry As Storage) est un client et un ensemble de conventions pour traiter un registre OCI comme dépôt d’artefacts typés. Un dépôt Maven / npm / NuGet « classique » expose des métadonnées et des layouts propres à l’écosystème ; le comparatif utile en CI Mac n’est pas « lequel est supérieur », mais quel transport et quelle surface d’audit vous standardisez quand plusieurs langages cohabitent.

Si votre équipe vit déjà dans Helm OCI ou GHCR, ORAS complète plutôt qu’il ne remplace les dépôts linguistiques — croisez avec la matrice Helm OCI pour les paramètres helm pull oci:// et la matrice GHCR pour les jetons et le parallélisme Docker.

Sur macOS, isolez le cache ORAS sous le répertoire du job pour éviter qu’un runner partagé ne mélange les blobs entre locataires. Le répertoire par défaut suit la variable ORAS_CACHE (préfixe de cache utilisé par le CLI) ; combinez-la avec un WORKDIR dédié par build.

Seuils d’eau recommandés sur le volume qui contient ORAS_CACHE et la sortie des artefacts : avertissement 80 %, ralentissement ou skip pré-pull 85 %, arrêt des nouveaux tirages 90 % — alignés sur une marge d’au moins 18–25 Go libres sur les configurations NVMe 512 Go typiques. Au-delà, purgez les jobs terminés avant d’accepter une nouvelle vague de oras copy.

Les paramètres ci-dessous sont des points de départ pour un Mac distant au-delà d’une frontière réseau sensible. Ajustez après une semaine de métriques (taux de 429, p95 des transferts, pression disque).

Variables et orchestration concurrente (copier-coller)

# Couche ORAS (téléchargements internes d’un même copy/pull)
export ORAS_CACHE="${WORKSPACE:-$PWD}/.oras-cache"
mkdir -p "$ORAS_CACHE"
export ORAS_COPY_CONCURRENCY=2

export REGISTRY="ghcr.io"
export NS_REPO="MON_ORG/MON_DEPOT"
export OUT_DIR="${WORKSPACE:-$PWD}/artifact-out"
mkdir -p "$OUT_DIR"

# Plusieurs tags en parallèle (ajuster -P selon la matrice « Prudent / Équilibré »)
printf '%s\n' "v1.0.0-artifact" "v1.0.0-config" | xargs -I{} -P 2 \
  sh -c 'oras pull "$REGISTRY/$NS_REPO:$1" -o "$OUT_DIR/$1"' _ {}

# Digest figé (recommandé en CI)
DIGEST="$(oras resolve "${REGISTRY}/${NS_REPO}:v1.0.0-artifact")"
oras pull "${REGISTRY}/${NS_REPO}@${DIGEST}" -o "${OUT_DIR}/release"

Remplacez les identifiants par vos valeurs ; gardez oras resolve et le tirage par digest dans la même étape atomique du pipeline pour éviter les courses sur tag.

La porte d’acceptation distingue l’intégrité réseau (retry autorisé) de l’intégrité cryptographique (échec immédiat sans retry si incohérence). Exigez une liste de digests attendus générée lors de la publication et stockée comme artefact de « provenance ».

Checklist minimale : (1) oras resolve sur la référence publiée ; (2) comparaison au digest attendu dans le fichier de gate ; (3) après oras pull, shasum -a 256 sur chaque fichier critique et comparaison aux empreintes attendues ; (4) pour les bundles multi-fichiers, vérifier aussi la taille attendue pour détecter les troncatures partielles.

# Vérification digest manifeste (échec immédiat si divergence)
EXPECTED_DIGEST="sha256:COLLEZ_LE_DIGEST_PUBLIE"
RESOLVED="$(oras resolve "${REGISTRY}/${NS_REPO}:v1.0.0-artifact")"
test "$RESOLVED" = "$EXPECTED_DIGEST"

# Après extraction : checksum des livrables (macOS)
cd "${OUT_DIR}/release"
shasum -a 256 --check sommes_attendues.sha256

Si shasum échoue, ne relancez pas aveuglément le pull : investiguez substitution de tag, proxy de cache corrompu ou attaque supply-chain. Pour la stabilité générale des pulls (Git, Homebrew, npm), ouvrez plutôt le FAQ reprise transfrontalière — hors périmètre ORAS mais utile sur le même hôte.

ORAS remplace-t-il Nexus ou Artifactory ? Non : ce sont des registres ou dépôts ; ORAS standardise le pull/push OCI. Vous pouvez toutefois exposer des artefacts OCI derrière les produits qui supportent l’API registry v2.

ORAS_COPY_CONCURRENCY s’applique-t-il à oras pull ? Il gouverne surtout le parallélisme interne des opérations de type copy multi-couches ; pour oras pull, gardez la même valeur comme plafond raisonnable et bornez surtout xargs -P pour les références multiples.

Faut-il aligner ORAS et Docker sur le même cache ? Non : les layouts diffèrent. En revanche, alignez la politique de retry et les seuils disque pour que les playbooks d’astreinte restent lisibles.

Comment tracer les échecs 401 intermittents ? Jeton proche de l’expiration, horloge dérivée, ou quota OIDC : renouvelez l’auth en tête de job et comparez l’heure NTP du Mac distant.

En 2026, traiter les artefacts de build comme des objets OCI simplifie l’auth et les audits, à condition de figer les digests, de borner ORAS_CACHE et la concurrence, et d’appliquer une porte checksum sans retry naïf. Choisissez ORAS quand le registre est déjà le centre de gravité ; conservez les clients natifs là où le lockfile l’emporte.