`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]>
Un CronJob toutes les 5 minutes interroge Prometheus depuis dehors et pousse
lui-même sur Telegram. Il couvre les trois morts, dont celle qui est arrivée :
répondre parfaitement en n'enregistrant rien.
Éprouvé en vrai sur le cluster : 187 s entre la panne armée et le message
accepté par Telegram, mesuré deux fois. Contre 4620 minutes de silence réel.
Ferme #36.
Co-Authored-By: Claude Opus 5 <[email protected]>
Co-authored-by: Gabriel Radureau <[email protected]>
Quatre runs d'une branche déjà mergée ont bloqué, ce matin, l'apply qu'on
attendait. Deux causes, indépendantes :
1. Les workflows tofu (minio, vault, crowdsec, plausible) s'authentifient à
Vault par un flux OIDC dont un HUMAIN doit ouvrir le lien. Déclenchés tout
seuls, ils ne peuvent qu'occuper un runner jusqu'au timeout. Ils font en
plus `apply` en `auto_approve` CONTRE LA PROD : partir sur le push d'une
branche, c'est appliquer du code que personne n'a relu. → `workflow_dispatch`
seul, ce qui écrit enfin ce qu'ils faisaient déjà.
(crowdsec et plausible passaient de toute façon par une ancre YAML, donc
leurs triggers étaient INERTES — issues 113 → 117 de kadans.)
2. `push` sur toutes les branches + `pull_request` = DEUX runs par commit dès
qu'une branche a une PR. Vérifié : runs 258/259 et 260/261 portent le même
SHA. helmcharts, qui travaille seul et mérite de rester automatique, prend
la forme éprouvée de la CI de kadans : push sur `main`, PR pour la branche.
Chaque clé de trigger porte un corps explicite : un `pull_request:` nu n'est
pas une forme éprouvée ici, et son mode d'échec est le silencieux.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
arcodangeandClaude Opus 5