Ce dépôt ne contient aucun code C#. Il porte uniquement de quoi installer sur YunoHost une archive déjà compilée : le manifeste, les configurations nginx et systemd, et les scripts d'installation.

Contenu

Fichier	Rôle
`manifest.toml`	Identité, version, URL de l'archive et son `sha256`, ressources (utilisateur système, répertoires, port, permissions)
`conf/systemd.service`	Unité du service — écoute sur `127.0.0.1`, base dans le répertoire de données, durcissement
`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-release.sh`	Compile, archive, calcule le `sha256` et met à jour `manifest.toml`

Publier une nouvelle version

Le serveur ne compile jamais : il télécharge une archive déjà produite. La chaîne est donc « compiler ici, déposer une release, mettre à jour le manifeste ».

# Depuis ce dépôt, avec le dépôt du code à côté (../mabibli)
./build/publier-release.sh --version 0.1.1

Le script :

lance dotnet publish MaBibli.Api -c Release -r linux-x64 --self-contained ;
vérifie que le binaire est là, que wwwroot/ a bien été embarqué, et que toutes les ressources référencées par index.html existent réellement dans le publish ;
produit build/dist/mabibli-<version>-linux-x64.tar.gz, de façon reproductible ;
en calcule le sha256 ;
réécrit version, amd64.url et amd64.sha256 dans manifest.toml.

Restent à faire à la main : créer le tag et la release sur Gitea, y téléverser l'archive, puis committer et pousser manifest.toml — YunoHost lit le manifeste depuis Gitea, pas la copie locale.

📖 La marche à suivre complète est dans PUBLICATION.md : première mise en production, montée de version (avec les contrôles à chaque étape), retour arrière, et désinstallation.

Le script ne dépend d'aucun environnement de CI : tout passe par des options ou des variables d'environnement (MABIBLI_SOURCE_DIR, MABIBLI_VERSION, MABIBLI_BASE_URL, MABIBLI_OUTPUT_DIR), il ne pose aucune question et s'arrête à la première erreur. Il est donc utilisable tel quel dans Gitea Actions le jour où un runner sera disponible.

Points de conception

Le service n'écoute que sur 127.0.0.1. L'application déduit l'identité de l'en-tête YNH_USER injecté par SSOwat ; cet en-tête n'est digne de confiance que si nginx est le seul chemin d'accès. Un service exposé sur le réseau permettrait de forger YNH_USER et de contourner le portail. La contrainte est écrite dans conf/systemd.service (ASPNETCORE_URLS) et le port n'est pas ouvert au pare-feu.

Aucune compilation sur le serveur. Le publish est self-contained : il embarque son propre runtime .NET, donc aucun paquet dotnet-runtime n'est nécessaire. ynh_setup_source vérifie le sha256 de l'archive avant de la déployer.

Les données survivent aux mises à jour. La base SQLite vit dans le répertoire de données, pas à côté du binaire ; upgrade ne remplace que le répertoire d'installation.

La sauvegarde passe par l'API de sauvegarde en ligne de SQLite. La base est en mode WAL : copier le seul fichier .db d'une base active peut ne rien sauvegarder du tout. Voir doc/ADMIN.md.

Documentation

doc/DESCRIPTION.md — présentation affichée dans le catalogue YunoHost
doc/ADMIN.md — authentification, emplacement des données, sauvegarde, contraintes
PUBLICATION.md — mise en production et montée de version, pas à pas
A_FAIRE.md — contraintes permanentes et journal des points réglés