`main` est rouge depuis la fusion de #39 : `Application charts prometheus`,
`curl` code 6, « couldn't resolve host ». Le repli DNS ajouté par cette PR-là
avait été posé sur la DESCENTE des dépendances seulement ; l'étape de
PUBLICATION était restée sur le nom d'origine. Un remède qui vit à deux
endroits ne se propage pas par la vigilance — le commentaire le dit désormais
à l'endroit où quelqu'un ajoutera le troisième appel.
Et en le corrigeant, un second défaut, plus grave parce qu'il est muet :
`curl` rend 0 sur un 401 comme sur un 409. L'étape passait au VERT en ne
publiant rien. Mesuré le 2026-09-07 : le registre interne ne contenait que
`minio 0.2.0` et `tool 0.1.0` — DEUX charts sur DIX — sans que rien n'ait
jamais rougi. On relève donc le code HTTP et on en décide ; le code de sortie
de `curl`, lui, ne parle que du transport.
409 est ACCEPTÉ et nommé : republier une version inchangée est le cas normal
d'un lot qui ne touche pas au `version:` du chart, pas une faute.
Éprouvé par sabotage, faux `curl` piloté, vrai shell du runner
(`bash -e -o pipefail`), les deux côtés mesurés :
cas AVANT APRÈS
nom KO, repli KO exit 6 exit 1 « le registre est injoignable »
nom KO, repli OK — exit 0 publié via la passerelle
registre REFUSE (401) exit 0 exit 1 « publication REFUSÉE »
déjà publié (409) exit 0 exit 0 « déjà présent, rien à republier »
tout va bien (201) exit 0 exit 0
⚠ Le jeton part par le repli, alors que la descente est anonyme. Ce n'est pas
une exposition neuve : `actions/checkout` pose déjà son `extraheader` porteur
du jeton de forge sur cette même URL de passerelle, à chaque job.
⚠ Trois fois de suite, mon banc a rendu un verdict faux avant de rendre le
vrai : trace `set -x` prise pour de la sortie, variables qui n'atteignaient
pas le script, puis `IFS` fuyant d'un `read` sous zsh et collant les
affectations en une seule. Aucun verdict n'a été tiré sans avoir vérifié que
le décor était posé — le banc l'imprime.
Co-Authored-By: Claude Opus 5 <[email protected]>
arcodangeandClaude Opus 5