La publication du chart n'atteignait pas le registre, et ne pouvait pas le dire (#42)

Le repli DNS était posé sur la descente des dépendances seulement ; la
publication restait sur le nom d'origine, d'où le code 6 qui a rougi main.

Et le second défaut, muet : curl rend 0 sur un 401 comme sur un 409, donc
l'étape passait au vert en ne publiant rien. Le registre ne contenait que
deux charts sur dix, sans que rien n'ait jamais rougi.

Co-Authored-By: Claude Opus 5 <[email protected]>
Co-authored-by: Gabriel Radureau <[email protected]>

.gitea/workflows/helmcharts.yaml

@@ -285,7 +285,50 @@ jobs:
           chart_package=${chart}-${chart_version}.tgz
           # helm package ${chart}
           tar -X ${chart}/.helmignore -czf ${chart_package} ${chart}
-          curl --user ${{ github.actor }}:${{ secrets.PACKAGES_TOKEN }} -X POST --upload-file ./${chart_package} https://gitea.arcodange.lab/api/packages/${{ github.repository_owner }}/helm/api/charts
+
+          # ⚠⚠ LE MÊME REPLI QUE POUR LA DESCENTE DES DÉPENDANCES, ET C'EST
+          # POURQUOI CE COMMENTAIRE EXISTE. Le correctif du 2026-09-07 n'avait
+          # posé le repli QUE sur `helm_install_dependencies` ; celui-ci est
+          # resté sur le nom d'origine, et `main` est devenu rouge dès la
+          # fusion suivante — `curl` code 6, « couldn't resolve host ».
+          # **Un remède qui vit à DEUX endroits ne se propage pas par la
+          # vigilance.** Si un troisième appel au registre apparaît un jour, il
+          # a besoin de ces trois lignes lui aussi.
+          FORGE_INTERNE='https://gitea.arcodange.lab'
+          registre="${FORGE_INTERNE}/api/packages/${{ github.repository_owner }}/helm"
+          if ! curl -sf -o /dev/null -m 15 "${registre}/index.yaml"; then
+            repli="${registre/$FORGE_INTERNE/${GITHUB_SERVER_URL:-$FORGE_INTERNE}}"
+            if [[ "$repli" != "$registre" ]] && curl -sf -o /dev/null -m 15 "${repli}/index.yaml"; then
+              echo "  ⚠ ${registre} injoignable depuis ce runner — repli sur ${repli}"
+              registre="$repli"
+            fi
+          fi
+
+          # ⚠ ICI LE JETON PART, alors que la descente est anonyme. Le repli est
+          # `http://192.168.65.254:43000` — la passerelle Docker de l'hôte, en
+          # clair. Ce n'est pas une exposition NEUVE : `actions/checkout` pose
+          # déjà son `http.<cette-url>.extraheader` porteur du jeton de forge à
+          # chaque job. Même chemin, même machine, même classe de risque.
+
+          # ⚠⚠ ET L'APPEL DOIT POUVOIR ÉCHOUER. `curl` rend 0 sur un 401 comme
+          # sur un 409 : l'étape passait au vert en ne publiant rien. On relève
+          # donc le CODE HTTP (`-w`) et on en décide — le code de sortie de
+          # `curl`, lui, ne parle que du transport. Mesuré le 2026-09-07 : le
+          # registre ne contenait que `minio 0.2.0` et `tool 0.1.0`, deux
+          # charts sur dix, sans que rien n'ait jamais rougi.
+          # ⚠ `409` est ACCEPTÉ et nommé : republier une version inchangée n'est
+          # pas une faute, c'est le cas normal d'un lot qui ne touche pas au
+          # `version:` du chart. Tout autre code arrête le job.
+          code=$(curl -s -o /tmp/publication.out -w '%{http_code}' \
+            --user ${{ github.actor }}:${{ secrets.PACKAGES_TOKEN }} \
+            -X POST --upload-file ./${chart_package} \
+            "${registre}/api/charts") || { echo "✖ curl a échoué (code $?) — le registre est injoignable"; exit 1; }
+          cat /tmp/publication.out || true
+          case "$code" in
+            2??) echo "✓ ${chart_package} publié (HTTP $code)" ;;
+            409) echo "✓ ${chart_package} déjà présent au registre (HTTP 409) — rien à republier" ;;
+            *)   echo "✖ publication REFUSÉE (HTTP $code) — le chart n'est PAS au registre"; exit 1 ;;
+          esac
 
   application-charts:
     <<: *charts-matrix-job