diff --git a/docs/architecture.md b/docs/architecture.md index 2b1909b..c809f6b 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -621,7 +621,7 @@ Déclenché par les tags `v*`. Un seul job, `build-and-release`, dans un contene Fonctionnalités : - Signature des binaires (clés TAURI_SIGNING_PRIVATE_KEY) -- JSON d'updater (`latest.json`) écrit par `scripts/build-latest-json.sh` à partir des assets ([#320](https://git.lacompagniemaximus.com/maximus/simpl-resultat/issues/320)). `tauri-plugin-updater` cherche `{os}-{arch}-{installer}`, puis `{os}-{arch}` : le fichier porte `linux-x86_64-deb` et `linux-x86_64-rpm` (une clé par paquet Linux), `linux-x86_64` (le `.deb`, repli d'un binaire sans type de paquet connu, condition de retrait dans `docs/qa-update-cycle.md`) et `windows-x86_64` (l'installeur NSIS). Le script échoue s'il ne trouve pas exactement un `.deb`, un `.rpm` et un `-setup.exe`, chacun avec un `.sig` non vide ; le JSON vient de `jq` seul (notes lues comme données par `--rawfile`), avec les noms de fichiers encodés par `@uri`, comme à l'envoi des assets. Testé par `scripts/build-latest-json.test.mjs` (vitest, lancé par `check-frontend`), qui l'exécute sous `bash -e -o pipefail` comme `release.yml`. +- JSON d'updater (`latest.json`) écrit par `scripts/build-latest-json.sh` à partir des assets ([#320](https://git.lacompagniemaximus.com/maximus/simpl-resultat/issues/320)). `tauri-plugin-updater` cherche `{os}-{arch}-{installer}`, puis `{os}-{arch}` : le fichier porte `linux-x86_64-deb` et `linux-x86_64-rpm` (une clé par paquet Linux), `linux-x86_64` (le `.deb`, en repli : raison, lecteurs connus et condition de retrait dans `docs/qa-update-cycle.md`) et `windows-x86_64` (l'installeur NSIS). Le script échoue s'il ne trouve pas exactement un `.deb`, un `.rpm` et un `-setup.exe`, chacun avec un `.sig` non vide ; le JSON vient de `jq` seul (notes lues comme données par `--rawfile`), avec les noms de fichiers encodés par `@uri`, comme à l'envoi des assets. Testé par `scripts/build-latest-json.test.mjs` (vitest, lancé par `check-frontend`), qui l'exécute sous `bash -e -o pipefail` comme `release.yml`. - JSON publié sur `https://git.lacompagniemaximus.com/api/packages/maximus/generic/simpl-resultat/latest/latest.json` (registre de paquets, endpoint de `tauri.conf.json`). Avant le `DELETE` de l'ancienne version, une assertion `jq` (version égale au tag, exactement les quatre clés, signatures non vides, extension de chaque URL) arrête le job si le fichier ne la passe pas : le registre reste intact. - Release Forgejo automatique avec assets et release notes extraites du CHANGELOG.md, transmises par `GITHUB_OUTPUT` sous un délimiteur aléatoire (une ligne du CHANGELOG égale à un délimiteur fixe terminait la valeur) diff --git a/docs/qa-update-cycle.md b/docs/qa-update-cycle.md index ac3411b..5691bfa 100644 --- a/docs/qa-update-cycle.md +++ b/docs/qa-update-cycle.md @@ -74,7 +74,7 @@ Même parcours que le §2, sur la machine Fedora ou openSUSE. L'updater y lance - [ ] Authentifier → `readyToInstall`, puis cliquer → `installing`, l'app redémarre. - [ ] Vérifier la version, re-vérifier → `upToDate`. - > Un refus juste après le téléchargement (« format de mise à jour invalide ») est le défaut d'avant #320 : l'installation a reçu le `.deb`. Vérifier que le `latest.json` publié porte la clé `linux-x86_64-rpm` (`verify-release.sh`, étape 9 de `/release`). + > Une erreur `invalid updater binary format` sur la carte, juste après le téléchargement, est le défaut d'avant #320 : l'installation a reçu le `.deb` et l'a refusé. Vérifier que le `latest.json` publié porte la clé `linux-x86_64-rpm` (`verify-release.sh`, étape 9 de `/release`). **Pas encore déroulé** : aucune machine Fedora ou openSUSE n'était disponible quand #320 a ajouté la clé `linux-x86_64-rpm`. Le dérouler dès qu'il y en a une ; d'ici là, l'écrire « non déroulé », avec la raison, dans la trace de la release. @@ -88,10 +88,17 @@ Les installations `.rpm` existantes n'ont rien à réinstaller : le binaire du ` |---|---|---| | `linux-x86_64-deb` | `.deb` | les installations `.deb` | | `linux-x86_64-rpm` | `.rpm` | les installations `.rpm` (#320) | -| `linux-x86_64` | `.deb` | un binaire Linux sans marqueur de type de paquet (repli) | +| `linux-x86_64` | `.deb` | un binaire Linux sans marqueur de type de paquet, et les AppImage v0.4.2 à v0.4.5 (repli, voir ci-dessous) | | `windows-x86_64` | `-setup.exe` | les installations NSIS, qui cherchent d'abord `windows-x86_64-nsis` | -**Repli `linux-x86_64`.** Raison : un binaire sans marqueur de type de paquet ne cherche que cette clé ; sans clé à son nom, sa vérification échoue (`TargetsNotFound`) au lieu de répondre. Condition de retrait : quand aucune version supportée n'est antérieure au marqueur. Relevé le 2026-10-10 : toutes les versions qui embarquent l'updater (v0.2.1 et suivantes) ont été empaquetées par `@tauri-apps/cli` 2.10.0, d'après le `package-lock.json` de chaque tag, comme la v0.17.1 dont le `.rpm` porte le marqueur. Un binaire sans marqueur ne saurait d'ailleurs pas installer le `.deb` : faute de type connu, l'updater le traite comme une AppImage. +**Repli `linux-x86_64`.** Raison : un binaire sans marqueur de type de paquet ne cherche que cette clé ; sans clé à son nom, sa vérification échoue (`TargetsNotFound`) au lieu de répondre. Condition de retrait : quand aucune version supportée n'est antérieure au marqueur. Relevé le 2026-10-10 : toutes les versions qui embarquent l'updater (v0.2.1 et suivantes) ont été empaquetées par `@tauri-apps/cli` 2.10.0, d'après le `package-lock.json` de chaque tag, comme la v0.17.1 dont le `.rpm` porte le marqueur. + +Les lecteurs connus de cette clé ne savent pas installer le `.deb` qu'elle sert : + +- un binaire sans marqueur, lancé hors de son paquet ; +- les AppImage des v0.4.2 à v0.4.5, publiées sur Forgejo pour les v0.4.2 et v0.4.3 et sur le miroir GitHub pour les v0.4.3 à v0.4.5. Leur updater lit déjà le registre, et elles cherchent `linux-x86_64-appimage`, absente, puis cette clé. + +Pour les deux, l'updater traite le téléchargement comme une AppImage (`install_appimage`) et écrit les octets du `.deb` à la place du fichier lancé, ce qui casse l'installation. C'est l'état depuis la v0.4.2, que #320 ne change pas. --- diff --git a/scripts/build-latest-json.sh b/scripts/build-latest-json.sh index c842118..5d8ab00 100755 --- a/scripts/build-latest-json.sh +++ b/scripts/build-latest-json.sh @@ -29,8 +29,10 @@ # linux-x86_64 the .deb again: the fallback of a binary without a # bundle-type marker, which looks up this key alone. # Remove it once no supported version predates the -# marker (docs/qa-update-cycle.md, "Les clés de -# latest.json"). +# marker. AppImage installs (v0.4.2 to v0.4.5) read it +# too, and neither they nor a marker-less binary can +# install a .deb: see docs/qa-update-cycle.md, "Les +# clés de latest.json". # windows-x86_64 the NSIS installer. An NSIS install looks up # windows-x86_64-nsis first, then this key. #