92 lines
3.2 KiB
Markdown
92 lines
3.2 KiB
Markdown
# À 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="/">` 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.
|