5a666f5ca5
The e2e stack shared production's Postgres — same server, same database, same table. Seeded robots sat in `users` beside real clinicians, and anything a test wrote, or a migration under test changed, landed on real data. Nothing about "run the tests" should be able to reach an account belonging to a person. Now it has a Postgres and a Redis of its own, both on tmpfs: created empty on every run, held in RAM, gone on teardown. scripts/e2e.sh is one command that recreates the stack, seeds it, runs the browser and leaves the app up at 127.0.0.1:3553 so it can be clicked around in, with the report served at :3554. Two bugs fell out of it immediately, both of which only a database that did not already exist could have found: The schema could not be built from nothing. The entrypoint migrated before the app created its baseline tables, so the first migration failed on saved_encounters not existing. It never showed because every database this has ever run against already had the baseline. Then, one layer down, 1777800000000_generated-images creates a table with a foreign key to learning_content — which the baseline stopped creating when Learning Hub was removed. Restoring into a brand-new database could not have booted. The entrypoint now stands aside when the database is empty and lets the app do it in the order it already gets right, and the foreign key is only created where its target is. All 20 migrations replay from empty, producing the same 23 tables production has. Configuration lives in the database, so a throwaway one starts at defaults — 14 settings against production's 49. That is why every model picker was empty: models.custom did not exist. The tests were right and the environment was incomplete, so the seed now states what the suite depends on, with fictional model ids: a test should not pass because of a setting somebody changed on the live system last week. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Dv6sqaY6Vq3ChZHMem3cnU
27 lines
1.2 KiB
JavaScript
27 lines
1.2 KiB
JavaScript
// Prints one word: is this database already carrying the app's schema?
|
|
//
|
|
// ready the baseline tables exist; migrations can be applied on top
|
|
// empty nothing here yet
|
|
// unreachable could not connect or could not tell
|
|
//
|
|
// Used by docker-entrypoint.sh to decide whether it may migrate before the app
|
|
// starts. The schema has two layers — src/db/database.js creates the baseline
|
|
// with CREATE TABLE IF NOT EXISTS on first connect, and the migrations layer on
|
|
// top of it. Against an empty database the migrations fail, because the
|
|
// earliest of them alters a table only the baseline creates.
|
|
//
|
|
// Never exits non-zero: an answer of "unreachable" is for the caller to handle,
|
|
// and a database still opening its socket is not an error worth stopping on.
|
|
const { Client } = require('pg');
|
|
|
|
const client = new Client({ connectionString: process.env.DATABASE_URL });
|
|
client.connect()
|
|
.then(() => client.query("select to_regclass('public.users') is not null as ready"))
|
|
.then((result) => {
|
|
process.stdout.write(result.rows[0] && result.rows[0].ready ? 'ready' : 'empty');
|
|
return client.end();
|
|
})
|
|
.catch(() => {
|
|
process.stdout.write('unreachable');
|
|
try { client.end(); } catch (e) { /* already down */ }
|
|
});
|