feat(sandbox): add demo seed accounts via a context-gated liquibase changeset - #243
Merged
Conversation
…hangeset A fresh sandbox stack now boots with a small generic chart of demo accounts so it is immediately explorable. The data lives only in an idempotent Liquibase changeset (INSERT ... ON CONFLICT DO NOTHING with fixed UUIDs), never in a shell script or a client. Gating: the ledger Liquibase contexts default to production, so prod and Helm deployments skip the demo changeset; the compose sandbox opts in with production,demo. The schema-test harness migrates with the production context so the schema integration tests mirror production and never load demo rows. Closes #235
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
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.
Adds demo seed data so a fresh sandbox stack is immediately explorable (E-06, #235).
What
ledger/.../db/changelog/demo/001-demo-accounts.sql) inserting 5 generic chart-of-accounts demo rows (INSERT ... ON CONFLICT (id) DO NOTHING, fixed UUIDs,dbms:postgresql,context:demo). Data lives only in the migration, per the Data Integrity Rules - noseed.sh, no client hardcode.spring.liquibase.contextsdefaults toproduction(a non-demo sentinel), so production and Helm deployments skip the demo changeset. The compose sandbox opts in withSPRING_LIQUIBASE_CONTEXTS=production,demo.LedgerSchemaTestDb.migrate()) now migrates with theproductioncontext so the schema integration tests mirror production and never load demo rows.Why the context default matters
Liquibase runs every changeset when no runtime context is set, so a
context:demochangeset alone would still load in prod. Defaulting the runtime contexts toproductionactivates the filter; demo then loads only whendemois in the runtime contexts. No-context schema changesets always run, so this is back-compat for the existing schema.Verification
production,demo, so the demo changeset must apply cleanly against the real schema (every value validated against theaccountsCHECK constraints) for readiness to pass.ON CONFLICT DO NOTHINGplus Liquibase changeset tracking; production-skip is enforced by the context default (prod profile and Helm inject no demo context).Gate chain
dbms:postgresql, explicit NOT NULL column list, master-changelog replay).Contexts()harness impurity, fixed toContexts("production").Closes #235