Story: Bootstrap the system at runtime
Table of Contents
This page documents a story in Sprint 27. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
A freshly created database holds the schema and the staged DQ artefacts and
nothing else. The system is made usable at runtime, by running the ACME
provisioning through ores.shell (or ores.web's setup journeys), which
publishes the bundles in dependency order. A test that reads reference data
inserts or publishes it in its own setup.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 27 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-06 |
3. Acceptance
compass db recreatepublishes no reference data: refdata books, business units, asset classes and images hold no published rows.- The DQ artefacts are still staged, so the runtime provisioning has everything it needs to publish.
ores.shell(or ores.web) makes the system usable through the seed profiles; no build-time step is needed.- The test suite is green, with the tests that need reference data
publishing it through the shared
ores.testinghelper. - The memory records that the system is made usable by the runtime ACME provisioning.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Scaffold story: Bootstrap the system at runtime | DONE | 2026-10-06 | 2026-10-06 | Story scaffolding rides this task: documents, sprint wiring, and the scaffold PR. Close it before merging that PR. |
| Implement Bootstrap the system at runtime | DONE | 2026-10-06 | 2026-10-06 | Remove the build-time publish and add the shared test publish helper. |
5. Decisions
- One publish path, and it is the runtime one. The build-time bootstrap was added in PR #2034 because a fresh database had no published books and no trade could be booked. It duplicated the runtime publish and hand-ordered the calls, so it drifted from the dependency graph and published countries without the flag images their dependency declares. It goes.
- Staging stays at build time; publication moves out. The DQ artefacts are data the seeder generates and the build stages. Publishing them is a business operation the seed profiles drive, so it belongs to the runtime.
- Tests publish what they need.
ores.testinggainspublish_dataset()andpublish_refdata_dataset(), which make the same call the publish service makes. A test no longer leans on a build-time bootstrap that is not there.
6. Out of scope
- Attaching each service account's picture. It joins the published system
avatars, which now happens at runtime, so
iam_service_account_pictures_populate.sqlis not wired at build time and is named invalidation_ignore.txt. The runtime attach step is its own change. - End-to-end verification that
ores.shell bootstrap setupleaves a usable system. The seed profiles and the bundle publish are unchanged by this story; the check belongs with the shell work.