# Image pour héberger MaBibli AILLEURS que sur YunoHost (Synology, NAS, VPS…).
#
# ⚠️ Ce n'est PAS le chemin de déploiement de référence : celui-ci reste le paquet
# `mabibli_ynh`, qui déploie un publish self-contained sans conteneur (voir README,
# « Mettre en production »). Cette image existe pour les hébergements qui n'ont pas de
# portail SSO — et elle n'apporte donc AUCUNE authentification. Lire impérativement
# « Installer ailleurs que sur YunoHost » dans le README avant de l'exposer.

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src

# `MaBibli.Api` référence `MaBibli.Client` : le client Blazor WebAssembly est compilé au
# passage et atterrit dans `wwwroot/`. Un seul projet à publier suffit pour les trois.
# Aucun `dotnet workload install` n'est nécessaire : le SDK .NET 10 résout l'outillage
# WebAssembly tout seul (vérifié — aucune charge de travail n'est installée en local).
COPY . .
RUN dotnet publish MaBibli.Api --configuration Release --output /app

# Pas de `--self-contained` ici, contrairement au paquet YunoHost : l'image `aspnet`
# embarque déjà le runtime. Le self-contained sert à ne rien exiger d'un serveur qu'on
# ne maîtrise pas ; dans un conteneur, la question ne se pose pas.
FROM mcr.microsoft.com/dotnet/aspnet:10.0
WORKDIR /app
COPY --from=build /app .

# La base vit dans un volume, jamais à côté des binaires : c'est ce qui la fait survivre
# au remplacement de l'image. Même règle que le `data_dir` de YunoHost.
ENV ConnectionStrings__MaBibli="Data Source=/data/mabibli.db"
VOLUME ["/data"]

# L'image `aspnet` écoute déjà sur 8080 : poser `ASPNETCORE_URLS` ne ferait qu'écraser ce
# réglage et journaliser un avertissement à chaque démarrage. Pour changer de port,
# `ASPNETCORE_HTTP_PORTS`. ⚠️ Écouter sur toutes les interfaces est sûr DANS un conteneur —
# c'est la publication du port qui décide de l'exposition, voir `compose.yaml`.
EXPOSE 8080

ENTRYPOINT ["dotnet", "MaBibli.Api.dll"]