3.2 KiB
À faire avant la première installation
Deux points restés en suspens à la livraison du paquet, à traiter quand tu voudras déployer. Rien ici n'est bloqué par le code : tout fonctionne, il manque des informations que seul toi peux fournir.
1. Remplacer l'URL de démonstration et déposer la release
Le manifest.toml porte une URL fictive (gitea.example.org) : le paquet ne
pouvait pas connaître ton vrai domaine Gitea au moment de sa création. En l'état,
l'installation échouerait au téléchargement de l'archive.
Ce qu'il faut faire
a. Créer la release du code. Sur le dépôt mabibli (celui du code C#, pas
celui-ci) :
git tag v0.1.0
git push origin v0.1.0
Puis créer la release correspondante dans l'interface Gitea et y téléverser
l'archive build/dist/mabibli-0.1.0-linux-x64.tar.gz.
⚠️ L'archive fait 68 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.
b. Régénérer le manifeste avec la vraie URL :
./build/publier-release.sh --base-url <ton URL Gitea réelle>
Le script recompile, produit l'archive, calcule son sha256 et l'inscrit dans le
manifest.toml avec la bonne URL. Committer ensuite le manifeste modifié.
c. Chercher les autres occurrences du domaine fictif, qui ne sont pas couvertes par le script :
grep -rn "gitea.example.org" .
Elles se trouvent dans manifest.toml (champ upstream.code), README.md, et
conf/systemd.service (directive Documentation=).
Comment vérifier
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
S'ils diffèrent, l'installation s'interrompra à la vérification d'intégrité — ce qui est le comportement souhaité, mais autant le savoir avant.
2. 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="/">deindex.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.