arcodange
040712c736
Helm Charts / Detect changed charts (pull_request) Successful in 16s
Helm Charts / Library charts tool (pull_request) Skipped
Helm Charts / Application charts chart (pull_request) Skipped
Helm Charts / Application charts crowdsec (pull_request) Skipped
Helm Charts / Application charts grafana (pull_request) Skipped
Helm Charts / Application charts hashicorp-vault (pull_request) Skipped
Helm Charts / Application charts minio (pull_request) Skipped
Helm Charts / Application charts pgbouncer (pull_request) Skipped
Helm Charts / Application charts pgcat (pull_request) Skipped
Helm Charts / Application charts redis (pull_request) Skipped
Helm Charts / Application charts prometheus (pull_request) Successful in 53s
MESURÉ (run 6728, étape « RELEVÉ ») :
GITHUB_SERVER_URL=http://192.168.65.254:43000
--- gitea.arcodange.lab ---
PAS DE RÉSOLUTION (getent code 2)
curl: (6) Could not resolve host: gitea.arcodange.lab
--- prometheus-community.github.io ---
2606:50c0:8000::153 … http=404
Le runner résout parfaitement les registres publics et PAS le nom interne.
SEPT charts sur dix déclarent le registre Helm interne en dépendance —
crowdsec, grafana, hashicorp-vault, pgbouncer, pgcat, prometheus, redis :
depuis que #32 a énuméré les charts, leurs jobs mouraient TOUS à la même
seconde, avant la moindre étape utile. C'est un trou d'infrastructure que #32
a rendu visible, pas un défaut d'un lot.
Le repli n'est essayé QU'APRÈS avoir constaté que le nom d'origine ne répond
pas, et la réécriture des URLs de l'index ne se fait QUE si l'on est
effectivement en repli : sur un runner qui sait résoudre, rien ne change —
vérifié en local, code 0, deux dépendances téléchargées, aucune ligne de repli.
Lecture anonyme du registre vérifiée (HTTP 200) : aucun jeton n'entre ici.
⚠ Piège évité au passage : `[[ … ]] && url=…` sous `set -e` AVORTE le script
quand la condition est fausse. C'est un `if`.
Refs: arcodange-org/tools#36