Documente qu'il n'y a plus qu'un script, et pourquoi il refuse
La chaîne de publication n'a plus qu'un point d'entrée. README.md décrit `publier.sh` seul, ses deux refus (tag déjà pris, dépôt du code sale) et le mode `--archive-seule` pour la marche à pied ; CLAUDE.md acte la fusion et ce qu'elle empêche de refaire. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
mathieu
@@ -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 <url>` 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 <url>` 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.
|
||||
|
||||
Reference in New Issue
Block a user