Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ADR-037 — CI ARM seule (raspi-srv-2) + validation x86 par barrière pré-merge

Statut : Accepté (2026-06-24, validé par le BDFL). Companion d’ADR-031 (mesure en root), d’ADR-036 (filtrage par chemin) et de l’outillage xtask (gate barrier, cf. outillage-xtask.md) ; s’appuie sur le Principe 1 (rigueur des couches fondatrices) et ADR-014 (validation x86_64 ET aarch64). N’amende pas l’exigence de validation sur les deux arches.

Catégorie : Méthode (gouvernance technique / CI).

Contexte

La CI tournait sur deux runners self-hosted : speedy (Mac mini Intel, x86_64) et raspi-srv-2 (Raspberry Pi 4, aarch64), chacun rejouant test-coverage (fmt, clippy, test, couverture lignes/branches en root). Deux constats motivent une réorganisation :

  1. raspi-srv-2 est lent. Le Pi est le poste de coût dominant de chaque run ; le réserver à un rôle unique (valider que le code compile et passe la barrière sur ARM) maximise son utilité sans le surcharger.
  2. speedy et carbon sont désormais pilotés comme exécuteurs de tâches (agents Claude Code headless, cf. relais multi-machines). carbon (x86_64, 8 cœurs, 16 Go) est plus capable que speedy (4 cœurs, 8 Go) ; les deux peuvent porter la validation x86 avant merge, sur deux micro-architectures x86 différentes — couverture x86 plus robuste que l’unique runner d’origine.

Faire porter à la CI GitHub la validation x86 et ARM n’est donc plus le meilleur découpage : l’x86 peut être validé hors CI, par orchestration pré-merge.

Décision

1. La CI GitHub ne conserve que le runner ARM (air-aarch64, raspi-srv-2)

ci.yml exécute test-coverage sur aarch64 uniquement. Les jobs arch-indépendants (changes, supply-chain) basculent sur le runner ARM (seul runner CI restant). La CI ARM gate les PR et main côté ARM (compilation + barrière + planchers de couverture 96 lignes / 78 branches, inchangés).

2. La validation x86 est une « barrière pré-merge » hors CI

Avant tout merge sur main, la barrière complète est exécutée sur speedy ET carbon via cargo xtask barrier — strictement les mêmes contrôles que l’ancien runner x86 : fmt (stable + nightly), clippy -D warnings, cargo test --workspace, couverture lignes ≥ 96 / branches ≥ 78 en root (ADR-031), cargo audit / deny / machete, // SAFETY:, cohérence Cargo.toml ↔ DEPENDENCIES.md, check-c-surface. Un merge n’a lieu que si les deux machines x86 sont vertes et la CI ARM est verte.

3. speedy reste enregistré comme runner, mais hors workflows

Le service runner speedy (label air-x86_64) reste enregistré (pas de désenregistrement) ; il n’est simplement plus référencé par ci.yml. À l’ouverture publique, une barrière CI x86 sera rebranchée (on tranchera alors entre speedy et carbon comme runner x86 « officiel »).

4. Équivalence de validation préservée

L’invariant ADR-014 (« x86_64 ET aarch64 ») est tenu : ARM par la CI, x86 par la barrière pré-merge sur deux machines. La rigueur n’est pas réduite — elle est seulement déplacée pour l’x86, de la CI vers l’orchestration pré-merge.

Conséquences

  • raspi-srv-2 dédié à un rôle clair (CI ARM), sans validation x86 redondante à porter ; itérations plus lisibles.
  • Couverture x86 élargie : deux micro-architectures x86 (Mac mini Intel + carbon plus ancien) au lieu d’une.
  • Le gate x86 n’est plus imposé par GitHub. Sa garantie repose sur la discipline d’orchestration pré-merge (mainteneur / agent), pas sur la branch-protection. Acceptable en dépôt privé mono-mainteneur (modèle de confiance déjà posé par ADR-031) ; à rebrancher en CI à l’ouverture publique (Décision 3).
  • raspi-srv-2 devient un SPOF de la CI : s’il est indisponible, le gate ARM ne passe plus. Mitigation : la barrière x86 (speedy + carbon) reste disponible, et le runner Pi est supervisé en service persistant.
  • Cohérence outillage : cargo xtask barrier est la source unique de la barrière (déjà utilisée localement) ; aucun nouveau script à maintenir.

Alternatives écartées

  • Garder les deux runners CI (statu quo) : fait porter au Pi lent une validation x86 redondante avec ce que speedy/carbon peuvent faire hors CI, et immobilise speedy en runner alors qu’on veut l’exploiter comme exécuteur.
  • Sortir aussi l’ARM de la CI (tout en pré-merge) : rejeté — on perd le gate ARM automatique sur main et l’invariant ADR-014 ne serait plus garanti par la CI du tout. L’ARM natif fiable n’est par ailleurs pas fourni par les runners GitHub-hosted.
  • Désenregistrer speedy : inutilement destructif ; le garder enregistré permet une réactivation immédiate à l’ouverture publique (Décision 3).

Risques et mitigations

  • Un merge effectué sans avoir lancé la barrière x86 ferait passer du code non validé sur x86 vers main. → Mitigé par la discipline d’orchestration (la barrière x86 sur speedy + carbon est un prérequis explicite de merge, gravé dans cet ADR et dans docs/CI.md) ; résolu à l’ouverture publique par le rebranchement d’un gate CI x86.
  • Indisponibilité du Pi. → Le gate ARM est bloquant par conception ; on attend son rétablissement plutôt que de contourner (cohérent avec « rigueur > vitesse »).

Adoption

Câblage immédiat : ci.yml (matrice réduite à air-aarch64 ; changes et supply-chain sur air-aarch64), docs/CI.md mis à jour (runners, barrière x86 pré-merge, planchers). speedy conservé enregistré, retiré des workflows.