From f96b36c5485744a9e1ca9494bac6133646fbdd7d Mon Sep 17 00:00:00 2001
From: Johan LEROY <contact@johanleroy.fr>
Date: Tue, 4 Aug 2026 14:29:27 +0200
Subject: [PATCH] =?UTF-8?q?ci:=20un=20token=20de=20release=20refus=C3=A9?=
 =?UTF-8?q?=20doit=20faire=20=C3=A9chouer=20le=20job,=20pas=20passer=20ina?=
 =?UTF-8?q?per=C3=A7u?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Avec un NPM_TOKEN expiré, les trois workflows de release sont ressortis « réussis » alors qu'aucune
release n'avait été créée et qu'aucun asset n'était attaché : l'attache était en continue-on-error et
le script sortait en 0 quand l'API refusait le token. Diagnostiquer a demandé de comparer les assets
de releases pour comprendre ce que les logs auraient dit tout de suite.

Désormais : token ABSENT (fork, run sans secret) reste un cas légitime qui sort proprement, mais un
token PRÉSENT et refusé, ou un upload d'asset en échec, fait échouer le job avec un message qui nomme
les portées attendues. Les artefacts du run sont uploadés AVANT cette étape, donc un job rouge ne
perd aucun binaire.

L'attache du VSIX passe au même script partagé : elle dupliquait la logique, avec le même angle mort.
---
 .gitea/scripts/attach-release-assets.sh | 19 +++++++++++++---
 .gitea/workflows/desktop-release.yml    | 11 ++++-----
 .gitea/workflows/vscode-release.yml     | 30 ++++++-------------------
 3 files changed, 29 insertions(+), 31 deletions(-)

diff --git a/.gitea/scripts/attach-release-assets.sh b/.gitea/scripts/attach-release-assets.sh
index 6ed2561..221b77b 100755
--- a/.gitea/scripts/attach-release-assets.sh
+++ b/.gitea/scripts/attach-release-assets.sh
@@ -12,6 +12,10 @@ tag="${1:?tag manquant}"
 release_name="${2:?nom de release manquant}"
 shift 2
 
+# Token ABSENT : cas légitime (fork, run sans secret) → on sort proprement.
+# Token PRÉSENT mais refusé par l'API : anomalie, on doit ÉCHOUER. Sinon le job reste vert alors
+# qu'aucun asset n'est attaché et qu'aucune release n'est créée, ce qui s'est produit avec un token
+# expiré : trois workflows « réussis » et zéro fichier publié.
 if [ -z "${RELEASE_TOKEN:-}" ]; then
   echo "::notice::RELEASE_TOKEN absent, aucun asset attaché (les artefacts du run restent disponibles)."
   exit 0
@@ -30,8 +34,9 @@ if [ -z "$release_id" ]; then
 fi
 
 if [ -z "$release_id" ]; then
-  echo "::warning::impossible de résoudre ou créer la release ${tag}"
-  exit 0
+  echo "::error::impossible de résoudre ou créer la release ${tag} avec le token fourni."
+  echo "::error::vérifier que le secret porte les portées write:repository et write:package, et qu'il n'a pas expiré."
+  exit 1
 fi
 
 for f in "$@"; do
@@ -45,7 +50,15 @@ for f in "$@"; do
     curl -fsSL -X DELETE -H "$auth" "${api}/releases/${release_id}/assets/${existing}" || true
   fi
   echo "attaching $name"
-  curl -fsSL -X POST -H "$auth" -F "attachment=@${f}" "${api}/releases/${release_id}/assets?name=${name}"
+  if ! curl -fsSL -X POST -H "$auth" -F "attachment=@${f}" "${api}/releases/${release_id}/assets?name=${name}"; then
+    echo "::error::échec de l'upload de ${name}"
+    failed=1
+  fi
 done
 
+if [ "${failed:-0}" != "0" ]; then
+  echo "::error::au moins un asset n'a pas pu être attaché à ${tag}."
+  exit 1
+fi
+
 echo "Assets attachés à la release ${tag}."
diff --git a/.gitea/workflows/desktop-release.yml b/.gitea/workflows/desktop-release.yml
index 3907eec..9d05a7a 100644
--- a/.gitea/workflows/desktop-release.yml
+++ b/.gitea/workflows/desktop-release.yml
@@ -68,12 +68,13 @@ jobs:
             packages/desktop/release/*.blockmap
             packages/desktop/release/latest-linux.yml
             packages/desktop/release/SHA256SUMS-linux.txt
-      # Best-effort : attache les installeurs (+ latest-linux.yml pour l'auto-update) à la release du
-      # tag. Réutilise NPM_TOKEN (même token Gitea) : il doit porter write:repository en plus de
-      # write:package, sinon l'API release renvoie 403 (les artefacts du run restent disponibles).
+      # Attache les installeurs (+ latest-linux.yml pour l'auto-update) à la release du tag. Réutilise
+      # NPM_TOKEN (même token Gitea) : il doit porter write:repository en plus de write:package, sinon
+      # l'API release renvoie 403. Pas de continue-on-error : les artefacts du run sont déjà uploadés à
+      # l'étape précédente, donc un échec ici ne perd rien et doit être VU (avec un token expiré, la
+      # release ressortait verte et vide).
       - name: Attach installers to the tag release
         if: github.event_name == 'push'
-        continue-on-error: true
         env:
           RELEASE_TOKEN: ${{ secrets.NPM_TOKEN }}
         run: |
@@ -131,9 +132,9 @@ jobs:
             packages/desktop/release/*.blockmap
             packages/desktop/release/latest.yml
             packages/desktop/release/SHA256SUMS-windows.txt
+      # Pas de continue-on-error : cf. la note du job Linux.
       - name: Attach installers to the tag release
         if: github.event_name == 'push'
-        continue-on-error: true
         shell: bash
         env:
           RELEASE_TOKEN: ${{ secrets.NPM_TOKEN }}
diff --git a/.gitea/workflows/vscode-release.yml b/.gitea/workflows/vscode-release.yml
index b8891c4..8f75ccc 100644
--- a/.gitea/workflows/vscode-release.yml
+++ b/.gitea/workflows/vscode-release.yml
@@ -45,31 +45,15 @@ jobs:
         with:
           name: vsix
           path: packages/vscode/*.vsix
-      # Best-effort : attache le VSIX à la release Gitea du tag (crée la release si absente).
-      # Réutilise le secret NPM_TOKEN (même token Gitea que la publication du daemon) : ce token doit
-      # porter write:repository en plus de write:package, sinon l'API release renvoie un 403. Sans
-      # token, l'étape est ignorée sans faire échouer le job (continue-on-error) ; le VSIX reste
-      # disponible en artefact.
+      # Attache le VSIX à la release Gitea du tag (créée si absente), via le script partagé avec la
+      # release desktop : la logique était dupliquée, avec le même angle mort. Réutilise le secret
+      # NPM_TOKEN (même token Gitea que la publication du daemon), qui doit porter write:repository en
+      # plus de write:package. Sans token du tout, le script sort proprement ; avec un token REFUSÉ, il
+      # échoue, pour que l'anomalie soit visible (le VSIX reste dans les artefacts du run).
       - name: Attach VSIX to Gitea release
-        continue-on-error: true
         env:
           RELEASE_TOKEN: ${{ secrets.NPM_TOKEN }}
         run: |
-          if [ -z "$RELEASE_TOKEN" ]; then
-            echo "::notice::NPM_TOKEN absent : VSIX disponible en artefact uniquement."
-            exit 0
-          fi
-          api="${GITHUB_SERVER_URL}/api/v1/repos/${GITHUB_REPOSITORY}"
-          auth="Authorization: token ${RELEASE_TOKEN}"
           version=$(node -p "require('./packages/vscode/package.json').version")
-          vsix="packages/vscode/git-arboretum-${version}.vsix"
-          # id de release du tag, sinon création
-          rid=$(curl -fsSL -H "$auth" "${api}/releases/tags/${GITHUB_REF_NAME}" | node -p "JSON.parse(require('fs').readFileSync(0,'utf8')).id || ''" || true)
-          if [ -z "$rid" ]; then
-            rid=$(curl -fsSL -X POST -H "$auth" -H 'Content-Type: application/json' \
-              -d "{\"tag_name\":\"${GITHUB_REF_NAME}\",\"name\":\"Arboretum VSCode ${version}\"}" \
-              "${api}/releases" | node -p "JSON.parse(require('fs').readFileSync(0,'utf8')).id || ''")
-          fi
-          curl -fsSL -X POST -H "$auth" -F "attachment=@${vsix}" \
-            "${api}/releases/${rid}/assets?name=git-arboretum-${version}.vsix"
-          echo "VSIX attaché à la release ${GITHUB_REF_NAME}."
+          bash .gitea/scripts/attach-release-assets.sh "${GITHUB_REF_NAME}" "Arboretum VSCode ${version}" \
+            "packages/vscode/git-arboretum-${version}.vsix"