diff --git a/CLAUDE.md b/CLAUDE.md index dfa309b..8c4d4dc 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1934,15 +1934,18 @@ appris, pas ce qu'on en attendait. ### La chaîne, telle qu'elle tourne ``` -publier-release.sh → archive tar.gz (69 Mo, self-contained) → release Gitea - → manifest.toml (amd64.url + amd64.sha256) - → yunohost app install +publier.sh → archive tar.gz (69 Mo, self-contained) → release Gitea + → manifest.toml (amd64.url + amd64.sha256) → commit + push + → tag v + push → yunohost app upgrade ``` Le script est la seule source des trois valeurs qui doivent rester cohérentes : version, URL, sha256. ⚠️ Il ne réécrit **que** `manifest.toml` — les autres mentions de l'URL (`README.md`, `Documentation=` de l'unité systemd) sont à traiter à la main. +⚠️ **Il n'y a qu'UN script, depuis le 2026-08-21 — voir « Un seul script de +publication » ci-dessous.** Ne pas réintroduire d'étape appelable séparément. + ⚠️ **Le dépôt du code doit être public.** `ynh_setup_source` télécharge sans jeton. Gitea répond **404 et non 403** à un anonyme sur un dépôt privé : le symptôme est rigoureusement identique à « la release n'existe pas », ce qui envoie chercher au @@ -1952,6 +1955,34 @@ mauvais endroit. Contrôle qui tranche, hors session authentifiée : ⚠️ **YunoHost lit le manifeste depuis Gitea**, jamais la copie locale. Une correction non poussée est une correction qui n'existe pas — constaté deux fois. +### Un seul script de publication — fusion du 2026-08-21 + +Il y en avait deux : `publier.sh` (l'enchaînement complet) et `publier-release.sh` +(compiler, archiver, réécrire le manifeste). ⚠️ **Le mauvais des deux portait le nom le +plus convaincant** — « publier-release » sonne plus précis que « publier », et les deux +se ressemblent dans la complétion du shell. + +Lancé seul, il produisait les **deux moitiés** de la panne constatée ce jour-là : + +| Ce qu'il faisait | Conséquence | +|---|---| +| réécrire `manifest.toml` **sans committer** | `yunohost app upgrade` échoue sur le sha256 — et son **retour arrière échoue pour la même raison**, puisqu'il retélécharge la même source | +| accepter de recompiler une version dont le **tag existe déjà** | la release `v0.4.0` contenait en réalité **six commits de plus** que son tag, donc une application qui se déclare « 0.4.0 » sans l'être | + +Le second est le plus grave, et le plus silencieux : rien ne le signale, et c'est +précisément le numéro qu'on ira chercher dans « À propos » pour diagnostiquer un +appareil dépareillé (voir le lot Y). **Une release qui ment sur son contenu ruine le +seul repère dont on dispose.** + +Les deux scripts sont fondus dans `build/publier.sh`, qui refuse maintenant de publier +**avant de compiler** si le tag existe déjà (en nommant le commit du tag et celui de +HEAD) ou si le dépôt du code a des modifications non committées. + +⚠️ Le mode `--archive-seule` conserve la brique réutilisable en CI, mais **sous le même +nom** : il compile et archive sans toucher ni au manifeste ni à git, donc il ne peut +rien laisser à moitié publié. Ne pas recréer de second script — c'est la coexistence de +deux commandes voisines qui était le défaut, pas leur contenu. + ### Deux pièges systemd, tous deux invisibles hors d'un vrai serveur Ni l'un ni l'autre ne peut sortir d'un `dotnet run` ou d'un lancement du publish à la @@ -3016,7 +3047,7 @@ utilisateurs d'un service en réseau puissent en obtenir la source** : ce lien n ornement, c'est ce que la licence demande. L'application ne connaissait pas sa version : elle vivait dans le `manifest.toml` du dépôt -`mabibli_ynh` et dans les tags git, **jamais dans le binaire**. `build/publier-release.sh` pose +`mabibli_ynh` et dans les tags git, **jamais dans le binaire**. `build/publier.sh` pose désormais `-p:Version` et `-p:MaBibliDateBuild` (en respectant `SOURCE_DATE_EPOCH`), et l'API rend les deux par `GET /api/version`. diff --git a/README.md b/README.md index 6642b4a..8f64c93 100644 --- a/README.md +++ b/README.md @@ -91,8 +91,7 @@ fichier est le point d'entrée unique du projet. | `conf/nginx.conf` | Reverse proxy et intégration SSOwat | | `scripts/_common.sh` | Variables partagées et sauvegarde/restauration cohérente de la base SQLite | | `scripts/install` `remove` `upgrade` `backup` `restore` | Cycle de vie de l'application | -| `build/publier.sh` | Publie une version de bout en bout : version, archive, manifeste, commits, tag, push | -| `build/publier-release.sh` | Compile, archive, calcule le `sha256` et met à jour `manifest.toml` | +| `build/publier.sh` | **Seul script de publication** : version, archive, manifeste, commit et push du paquet, tag et push du code. `--archive-seule` compile sans rien publier | | `doc/DESCRIPTION.md` `doc/ADMIN.md` | Textes affichés par YunoHost lui-même (catalogue et interface d'administration) — ils doivent rester dans ce dépôt | ### Points de conception @@ -128,19 +127,27 @@ propose l'incrément, puis enchaîne tout ce qui suit : archive, manifeste, comm du paquet, tag et push du code, avec vérification côté distant. Il ne reste qu'à créer la release dans Gitea et y téléverser l'archive — le script en rappelle l'URL. -Sous le capot, c'est `build/publier-release.sh` qui produit l'artefact ; il s'utilise -seul quand on veut une archive sans rien publier : +⚠️ **Il n'y a qu'un seul script, et c'est délibéré.** Un second, `publier-release.sh`, +a existé jusqu'au 2026-08-21 : il compilait, archivait et réécrivait le manifeste, à +charge pour l'appelant de committer. Son nom inspirait plus confiance que celui du vrai +point d'entrée, et lancé seul il produisait exactement la panne du 2026-08-21 — un +`manifest.toml` corrigé mais non poussé, et une release `v0.4.0` contenant en réalité six +commits de plus que son tag. Les deux scripts sont fondus ; la brique réutilisable +subsiste sous la même commande : ```bash -./build/publier-release.sh --version 0.4.0 --no-manifest-update +./build/publier.sh --archive-seule ``` +Ce mode compile et archive, **sans toucher ni au manifeste ni à git** : il ne peut donc +rien laisser à moitié publié. + Ce script compile ce dépôt (`mabibli`) en `Release` self-contained, **vérifie** le résultat (binaire présent, `wwwroot/` embarqué, toutes les ressources d'`index.html` réellement sur disque, aucun placeholder d'empreinte non substitué), produit une archive `.tar.gz` reproductible, calcule son `sha256`, et met à jour `version`, -`amd64.url` et `amd64.sha256` dans `mabibli_ynh/manifest.toml` — sauf avec -`--no-manifest-update`. +`amd64.url` et `amd64.sha256` dans `mabibli_ynh/manifest.toml` — sauf en +`--archive-seule`. Il injecte au passage, dans l'assembly, la **version** (`-p:Version`) et un **horodatage de build** (`-p:MaBibliDateBuild`), que la page « À propos » de @@ -157,6 +164,15 @@ voulu. corrigé mais non poussé n'existe pas pour le serveur. C'est précisément ce que `publier.sh` empêche d'oublier. +Il refuse par ailleurs de publier dans deux cas, **avant de compiler** : + +| Refus | Ce qu'il évite | +|---|---| +| le tag `vX.Y.Z` existe déjà | une release qui ne contient pas le code que son tag désigne — arrivé le 2026-08-21, six commits d'écart, sans que rien ne le signale | +| le dépôt du code a des modifications non committées | une archive contenant du travail que le tag, lui, ne contient pas | + +Dans les deux cas il nomme le commit en cause et rappelle `--patch` ou `--archive-seule`. + **La marche à suivre complète et éprouvée**, pour les cas que `publier.sh` ne couvre pas — première mise en production, montée de version pas à pas, retour arrière, désinstallation — est en « Mettre en production » ci-dessous. @@ -193,30 +209,34 @@ sudo yunohost domain add mabibli.mondomaine.tld - Le SDK .NET est installé sur la machine de développement (`dotnet --version`). -#### A.2 Produire l'archive +#### A.2 Produire l'archive, le manifeste et le tag Depuis `mabibli_ynh`, avec le dépôt du code à côté (`../mabibli`) : ```bash -./build/publier-release.sh +./build/publier.sh --version 0.1.0 ``` Le script compile en `Release` self-contained, **vérifie le publish** (binaire présent, `wwwroot/` embarqué, toutes les ressources d'`index.html` réellement sur disque, aucun placeholder d'empreinte non substitué), produit l'archive de façon reproductible, en -calcule le `sha256`, et réécrit `version`, `amd64.url` et `amd64.sha256` dans -`manifest.toml`. +calcule le `sha256`, réécrit `version`, `amd64.url` et `amd64.sha256` dans +`manifest.toml`, **commite et pousse le paquet**, puis **tague et pousse le code**. À contrôler dans sa sortie : la ligne `binaire, wwwroot et ressources d'index.html : OK`, -et le `sha256` affiché — c'est celui que le manifeste porte désormais. +le `sha256` affiché — c'est celui que le manifeste porte désormais — et les deux `✓` de +la vérification côté distant. + +Il ne reste alors que A.3. Les étapes A.4 et suivantes décrivent ce que le script vient +de faire, pour le cas où l'on reprend à la main après un échec en cours de route +(`--archive-seule` s'arrête après l'archive, sans toucher au manifeste ni à git). #### A.3 Déposer la release -```bash -cd ../mabibli && git tag v0.1.0 && git push origin main --tags -``` +Le tag `v0.1.0` est déjà poussé par A.2 (`git tag v0.1.0 && git push origin main --tags` +si l'on reprend à la main). -Puis, **dans l'interface Gitea** : créer la release `v0.1.0` sur le dépôt `mabibli`, et y +**Dans l'interface Gitea** : créer la release `v0.1.0` sur le dépôt `mabibli`, et y téléverser `build/dist/mabibli-0.1.0-linux-x64.tar.gz`. Vérification, à faire **sans être authentifié** (autre navigateur, ou `curl` comme @@ -229,16 +249,25 @@ curl -fsSLI "https://git.akbar.nohost.me/mathieu/mabibli/releases/download/v0.1. Attendu : `HTTP/2 200`. Un 404 signifie soit que la release n'est pas déposée, soit que le dépôt est privé — les deux se ressemblent, commencer par vérifier la visibilité. -#### A.4 Pousser le paquet +#### A.4 Le paquet, sur Gitea -⚠️ **L'étape la plus facile à oublier.** `yunohost app install ` lit le manifeste +⚠️ **L'étape la plus facile à oublier quand elle est manuelle** — et celle qui a fait +échouer la mise à jour du 2026-08-21. `yunohost app install ` lit le manifeste **depuis Gitea**, jamais la copie locale : un manifeste corrigé mais non poussé n'existe -pas pour le serveur. +pas pour le serveur. A.2 s'en charge et vérifie l'arrivée par `git ls-remote` ; en +reprise à la main : ```bash cd ../mabibli_ynh && git add -A && git commit -m "Publier la version 0.1.0" && git push ``` +Le contrôle qui tranche, quel que soit le chemin suivi — c'est le manifeste **tel que le +serveur le lira** : + +```bash +curl -fsSL "https://git.akbar.nohost.me/mathieu/mabibli_ynh/raw/branch/main/manifest.toml" | grep amd64 +``` + #### A.5 Installer ```bash @@ -310,12 +339,16 @@ cours de route. Le code est prêt et committé dans `mabibli`. Depuis `mabibli_ynh` : ```bash -./build/publier-release.sh --version 0.1.1 +./build/publier.sh --archive-seule --version 0.1.1 ``` -⚠️ **`--version` est obligatoire ici.** Sans lui, le script déduit la version de -`manifest.toml` et reproduirait 0.1.0. Il remet aussi le suffixe à `~ynh1` : une -nouvelle version applicative repart toujours de 1. +⚠️ **`--version` est obligatoire ici.** En `--archive-seule`, sans lui, le script déduit +la version de `manifest.toml` et reproduirait 0.1.0. + +⚠️ **`--archive-seule` ne touche pas au manifeste** : `version` (avec son suffixe +`~ynh1` — une nouvelle version applicative repart toujours de 1), `amd64.url` et +`amd64.sha256` sont alors à réécrire à la main. C'est le prix de la marche à pied ; +`publier.sh` sans option le fait, et ne peut pas l'oublier. Note le `sha256` affiché — il ne sera plus jamais le même, même à code identique si les dépendances bougent.