Produktion
Die API wird als Multi-Arch-Docker-Image ausgeliefert, gebaut aus src/Schuly.API/Dockerfile.
Container-Image
- Der Build-Kontext ist
./src. DieCOPY-Pfade im Dockerfile sind relativ zu diesem Verzeichnis, nicht zur Repo-Wurzel. - Build-Stages: SDK-Build/Publish auf
mcr.microsoft.com/dotnet/sdk:10.0, Runtime aufmcr.microsoft.com/dotnet/aspnet:10.0. Einstiegspunkt istdotnet Schuly.API.dll. - Die
application.propertiesim Repo-Root (dieDirectory.Build.propsnormalerweise für die Version ausliest) ist nicht im Build-Kontext enthalten, daher wird das Image mit-p:Version=$VERSIONgebaut. Der Release-Workflow übergibt den Release-Tag alsVERSION; das hält die Assembly-Version des Hosts konsistent mit dem, wogegen zur Laufzeit geladene Plugins binden. - Das Image legt
/app/pluginsund/app/plugins-configfür zur Laufzeit geladene Plugins und deren Konfiguration pro Plugin vorab an.
Versionierung + Release
Einzige Quelle der Wahrheit: application.properties (<version>). src/Directory.Build.props liest sie über XmlPeek aus.
Das Veröffentlichen eines GitHub Release löst docker-publish-release.yaml aus:
sync-version- vergleicht den Release-Tag (ohne führendesv) mitapplication.properties. Bei Abweichung wird ein Branchrelease-sync/<version>mit aktualisierter Datei erstellt und der PR automatisch (squash) inmaingemergt.build-and-push-multiarch- bautlinux/amd64+linux/arm64aus./srcund pusht folgende Tags:ghcr.io/schulydev/schuly:<semver>sowie:<major>,:<major>.<minor>und:latest(latestnur für Nicht-Prereleases).<DOCKERHUB_USERNAME>/schuly:<semver>(Docker Hub, best-effort - der Login-Schritt istcontinue-on-error).
Migrationen beim Start
Der Container wendet EF-Core-Migrationen automatisch beim Start an (ApplyMigrations() in Program.cs → db.Database.Migrate()) und spielt den School-Systems-Katalog ein. Beim Deployment ist kein separater Migrationsschritt nötig; stelle nur sicher, dass die Datenbank über den SchulyDatabase-Connection-String erreichbar ist. Siehe Migrationen und Konfiguration.
