mabibli_ynh/A_FAIRE.md

À faire avant la première installation

État au 2026-08-18. Ce qui est fait est conservé en bas de page : le savoir pourquoi c'était à faire reste utile à la prochaine version.

---

1. Rendre le dépôt du code accessible sans authentification — BLOQUANT

ynh_setup_source télécharge l'archive sans jeton. Tant que le dépôt mabibli est privé, l'installation échoue au téléchargement.

Le symptôme, et pourquoi il induit en erreur

Constaté le 2026-08-18, sans authentification :

/mathieu/mabibli                      → 404
/mathieu/mabibli/releases             → 404
/api/v1/repos/mathieu/mabibli         → 404

Gitea répond 404 et non 403 à un visiteur anonyme sur un dépôt privé, pour ne pas révéler son existence. Le symptôme est donc exactement le même que « la release n'a pas été créée » ou « le fichier n'a pas été téléversé ». Ne pas chercher du côté de la release avant d'avoir réglé la visibilité : les deux causes sont indiscernables.

Que le dépôt existe bien est vérifiable autrement, par SSH (clé, donc authentifié) :

git ls-remote --tags origin

Ce qu'il faut faire

Dans Gitea, sur le dépôt mathieu/mabibli : Settings → Danger Zone → Make repository public. Le code est déjà sous AGPL-3.0-or-later, la publication est cohérente avec la licence.

Si le dépôt doit rester privé, il faut héberger l'archive ailleurs, sur une URL publique, et faire pointer --base-url dessus. Un jeton dans l'URL du manifeste serait à écarter : le manifeste est lu par YunoHost et lisible sur le serveur.

---

2. Créer la release et y téléverser l'archive

À faire (ou à vérifier — voir point 1, tant que le dépôt est privé on ne peut pas savoir si c'est déjà fait).

Le tag est déjà poussé : v0.1.0 → 922fd02. Reste à créer la release correspondante dans l'interface Gitea et à y téléverser :

build/dist/mabibli-0.1.0-linux-x64.tar.gz

⚠️ L'archive à téléverser est celle produite le 2026-08-18, sha256 e3316bd05cd71234403695bab405f48009d8d6186b0074235396d622c8c0caef. Une archive plus ancienne traînant sur le disque ne correspondrait plus au manifeste, et l'installation s'interromprait à la vérification d'intégrité — comportement voulu, mais autant ne pas s'y heurter.

⚠️ Elle fait 69 Mo : c'est normal, le publish est self-contained et embarque le runtime .NET. C'est précisément ce qui évite d'installer dotnet-runtime sur le serveur YunoHost.

Comment vérifier

curl -fsSLI "https://git.akbar.nohost.me/mathieu/mabibli/releases/download/v0.1.0/mabibli-0.1.0-linux-x64.tar.gz" | head -1

Doit répondre HTTP/2 200, sans être connecté. Et le sha256 du manifeste doit correspondre à l'archive réellement déposée :

sha256sum build/dist/mabibli-0.1.0-linux-x64.tar.gz
grep sha256 manifest.toml

---

3. Committer et pousser le paquet

Le manifeste corrigé n'est pas encore poussé. yunohost app install <url du dépôt> lit le manifeste depuis Gitea, pas depuis la copie locale : sans ce push, l'installation repartira sur l'ancienne URL fictive.

git add -A && git commit && git push

---

Contrainte permanente — ce n'est pas une tâche

L'application exige un domaine entier, pas un sous-chemin

Contrainte technique, pas un choix. MaBibli doit être installée sur mabibli.mondomaine.tld, et non sur mondomaine.tld/mabibli.

Pourquoi

Deux éléments sont figés à la compilation du client Blazor WebAssembly :

• la balise <base href="/"> de index.html, qui détermine la racine de toutes les URL de l'application ;
• les empreintes d'intégrité inscrites dans service-worker-assets.js, qui garantissent que le service worker sert bien les fichiers attendus.

Réécrire ces valeurs sur le serveur au moment de l'installation casserait les empreintes, donc le service worker, donc le fonctionnement hors-ligne. Et comme rien n'est recompilé côté serveur — c'est tout l'intérêt du déploiement self-contained —, il n'existe pas de solution propre pour un sous-chemin.

Le paquet déclare donc l'application en full_domain auprès de YunoHost, qui demandera un domaine dédié à l'installation.

Si tu voulais lever cette contrainte plus tard

Il faudrait produire une archive par chemin d'installation, ou recompiler sur le serveur. Les deux annulent le bénéfice du self-contained. À moins d'un besoin réel, un sous-domaine reste la bonne réponse.

---

Fait

L'URL de démonstration a été remplacée — 2026-08-18

Le manifest.toml portait une URL fictive (gitea.example.org) : le paquet ne pouvait pas connaître le vrai domaine Gitea au moment de sa création. Constaté en conditions réelles — l'installation s'arrête net au Prefetching asset main.

Corrigé par ./build/publier-release.sh, qui recompile, vérifie le publish, produit l'archive, calcule son sha256 et l'inscrit dans le manifeste avec la bonne URL. https://git.akbar.nohost.me/mathieu/mabibli/releases/download est désormais la valeur par défaut de --base-url dans le script : l'option n'est plus à passer.

Les occurrences hors manifeste, que le script ne touche pas, ont été traitées à la main : README.md et conf/systemd.service (directive Documentation=). Le contrôle reste grep -rn "gitea.example.org" . — il ne doit plus rien remonter que ce fichier-ci.

L'archive ne va plus dans git — 2026-08-18

build/dist/ est ignoré. L'archive vit dans la release Gitea ; committée, elle ajouterait 69 Mo d'historique par version, définitivement.