fix(scaffold): per-app volumes, init main, seed root admin on Aspire launch#1259
Merged
Conversation
Two DX fixes for scaffolded apps:
1. AppHost data volumes were literal ("postgres-data", "fsh-redis-data",
"fsh-minio-data"), so every FSH-based app on a machine (and this repo)
shared the same Docker volumes — one app's DB clobbered another's. Prefix
each volume with the AppHost name (e.g. "dentalos-postgres-data") so apps
get isolated, namespaced, safe volume names.
2. `fsh new` ran a bare `git init`, so the initial branch followed the user's
`init.defaultBranch` (often `master`). Force `main` via symbolic-ref on the
unborn HEAD (works on every git version) — the kit standardized on `main`.
The Aspire AppHost ran the migrator with bare `apply`, which migrates schema but never seeds the root admin user — so a freshly-run scaffolded app came up with an empty Users table and nobody could log in (admin@root.com). deploy/docker already used `apply --seed`; the Aspire dev path was inconsistent. Run `apply --seed` and pass the dev-default Seed__DefaultAdminPassword (mirrors the API's appsettings.Development.json) so `dotnet run AppHost` yields a working login out of the box. Verified end-to-end: fresh scaffold -> run -> log in as admin@root.com -> exercise tenants/users/catalog/audits APIs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three scaffolded-app DX fixes found while validating
fsh newend-to-end (a freshDentalOSscaffold → run → log in → exercise APIs).1. Seed the root admin on Aspire launch (the big one)
The AppHost ran the migrator with bare
apply, which migrates schema but never seeds the root admin — sodotnet run AppHostcame up with an emptyidentity.Userstable and nobody could log in. (deploy/dockeralready usedapply --seed; the Aspire path was inconsistent.) Now runsapply --seed+ passes the dev-defaultSeed__DefaultAdminPassword(mirrors the API'sappsettings.Development.json), soadmin@root.com/123Pa$$word!works out of the box.2. Per-app Docker volume names
AppHost data volumes were literal (
postgres-data,fsh-redis-data,fsh-minio-data), so every FSH-based app on a machine (and this repo) shared the same Docker volumes — one app's DB clobbered another's. Each volume is now prefixed with the AppHost name (e.g.dentalos-postgres-data).3. Init git on
main, notmasterfsh newran a baregit init, so the initial branch followed the user'sinit.defaultBranch(oftenmaster). Now forcesmainviasymbolic-ref(works on every git version), matching the kit's single-mainmodel.Verified end-to-end on a fresh
fsh new DentalOSmain; volumes =dentalos-postgres-dataetc. (no clash with other apps)/health/live+/health/ready— all green.🤖 Generated with Claude Code