feat(ci): construire l'image des jobs CI lourds sur chaque machine à runner (+ implémente l'épinglage de l'ADR 20260407) #48
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 CI BotandClaude Opus 5
|
9f438c4968 |
fix(ci_base_image) — l'image livrait Node 18 : deux défauts que seule sa CONSTRUCTION a montrés
J'avais écrit dans cette PR « je n'ai pas pu construire l'image, sa base vit
derrière le certificat interne ». C'était une SUPPOSITION NON TESTÉE, et elle est
fausse : `docker pull gitea.arcodange.lab/…/runner-images:ubuntu-latest-ca` passe
sans rien configurer. En la construisant vraiment, deux défauts sont sortis — et
aucun n'était visible à la lecture du Dockerfile.
1. `runner-images:ubuntu-latest-ca` LIVRE NODE 18 (v18.20.8). Or `nuxi` importe
`node:util.styleText`, absent de Node 18 : c'est la raison d'être du
`container: node:20-bookworm` de la CI de kadans, que son CLAUDE.md interdit
de retirer. Sans correctif, basculer la CI sur cette image cassait `nuxt build`
sur un message parlant d'un import introuvable — jamais d'une version de Node.
→ Node 20 installé depuis NodeSource.
2. ET INSTALLER NE SUFFISAIT PAS. Après l'installation, `node --version` rendait
TOUJOURS v18.20.8 : l'image de base précuit un node pour le toolcache d'act et
le met EN TÊTE du PATH.
which node → /opt/acttoolcache/node/18.20.8/arm64/bin/node
/usr/bin/node --version → v20.20.2 ← le bon, mais il PERD
→ l'entrée 18 du toolcache est retirée ; la résolution retombe sur
/usr/bin/node. ⚠ Conséquence assumée : `actions/setup-node` ne trouvera plus
de Node 18 préinstallé — aucun workflow de kadans ne l'utilise, et l'image
n'est servie qu'aux jobs qui DEMANDENT le label.
Le Dockerfile porte désormais une ASSERTION DE BUILD
(`node --version | grep -q "^v${NODE_MAJOR}\."`) : l'image ne peut plus se
construire si la résolution redevient mauvaise. Et le rôle vérifie la version au
déploiement (`failed_when`), au lieu de la supposer.
MESURES RÉELLES (construite en linux/arm64, l'architecture des runners) :
TOTAL 4,58 Go
├─ playwright install chromium 1,01 Go
├─ playwright install-deps 405 Mo
├─ Node 20 (NodeSource) 183 Mo
└─ bun 179 Mo
Vérifié dans l'image : which node → /usr/bin/node v20.20.2 · bun 1.3.14 ·
chromium-1228 + headless-shell + ffmpeg · /etc/ci-base.versions cohérent.
⚠ Ce que ces chiffres tranchent : le découpage en RUN séparés N'A PAS suffi à
rendre l'image poussable — 1,01 Go pour la plus grosse couche, soit ~4× les
261 Mo que le registre accepte (runner-images:ubuntu-latest-ca). Le build LOCAL
n'est donc pas une préférence, c'est la seule voie. Mesuré, plus supposé.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
||
|
CI BotandClaude Opus 5
|
fdecabf8ca |
feat(ci): construire l'image des jobs CI lourds sur chaque machine à runner
Les jobs CI du dépôt kadans réinstallent, à CHAQUE exécution, des choses qui
changent tous les trimestres. Mesuré le 2026-07-29 sur le run 628 (runner
ARM64, 2 vCPU / 3 Gio) :
npm install -g bun → 8,6 s
playwright install --with-deps chromium → 104,0 s (apt-get, à chaque run)
────────
112,6 s jetées par run, sur le
job qui EST le chemin critique
Le cache `actions/cache` ne peut rien contre ces 104 s : il couvre le NAVIGATEUR
(299 Mo déjà mis en cache), pas ses dépendances SYSTÈME — `--with-deps` relance
apt quoi qu'il arrive.
POURQUOI CONSTRUIRE ICI PLUTÔT QUE POUSSER UNE IMAGE. La tentative de publier
l'image au registre a échoué (kadans#224 puis #225) : 3,81 Go dont une couche
unique de 1,36 Go, `docker push` casse en « connection reset by peer » — 7
couches passent, 3 sont retentées 50 fois puis abandonnées. À titre de
comparaison, runner-images:ubuntu-latest-ca (534,7 Mo, plus grosse couche
261 Mo) passe sans problème : la limite est entre 261 Mo et ~500 Mo par couche.
Construire localement supprime le problème — aucune couche ne traverse le
réseau.
Et c'est bien sur CHAQUE machine : avec `capacity: 1`, le parallélisme vient de
plusieurs Raspberry, et `container:` est résolu par le runner. Un job qui
atterrit là où l'image manque échoue AVANT sa première étape.
Trois choix de conception :
1. L'image hérite de runner-images:ubuntu-latest-ca, donc du certificat de la CA
interne (step-ca). Repartir de node:20-bookworm obligerait à réinjecter le CA
à la main, et tout job parlant à gitea.arcodange.lab échouerait en TLS.
2. TROIS `RUN` séparés (bun / dépendances système / navigateur), délibérément.
La version qui a échoué faisait une couche de 1,36 Go. Ne pas les fusionner
pour « gagner une couche ».
3. L'image est ÉPINGLÉE par un conteneur factice — ce qui implémente enfin la
section 1 de docs/adr/20260407-docker-storage-gitea-runner.md, restée à
l'état de proposition : system_docker.yml n'applique que le data-root sur
disque externe et les log-opts. Sans épinglage, le ramasse-miettes de Docker
supprime l'image dès que le disque se remplit — panne déjà constatée sur les
images de runner elles-mêmes.
Le rôle vérifie sa sortie (`docker run … bun --version`) au lieu de supposer que
le build a suffi, et l'image écrit ses versions dans /etc/ci-base.versions pour
que la CI de kadans puisse les confronter à son bun.lock et échouer FORT sur une
dérive, plutôt que de la découvrir en « Executable doesn't exist ».
Nouveau label runner `ci-node-playwright`. `container.force_pull: false` est
déjà en place et devient REQUIS pour ce label : sans lui, act_runner tenterait
un pull d'une image qui n'est dans aucun registre.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|