Use the CLI in CI

Use the CLI to inspect a disposable database after your pipeline applies migrations and loads fixtures. A useful check verifies the objects and values the application expects, not only that the database process is running.

Provide the test connection#

Install the CLI in the runner. Supply connection credentials through the CI secret environment. A numbered environment profile avoids an interactive connection-save step:

export WHODB_POSTGRES_1='{"alias":"ci-postgres","host":"localhost","user":"postgres","password":"local-test-only","database":"app_test","port":"5432"}'

The example password is for a disposable local database. Replace the whole profile through your secret source for a real environment. The host must be reachable from the runner; a service container may use a service hostname instead of localhost.

Check the expected state#

Run a small connection diagnostic, then inspect the required objects and fields:

whodb doctor --connection ci-postgres --schema public --format json
whodb tables --connection ci-postgres --schema public --format json
whodb columns --connection ci-postgres --schema public --table users --format json

Use audit for supported data-quality checks and diff for schema comparisons when they fit the pipeline. Read each command's help and exit behavior before making it a gate. Capturing JSON is useful evidence, but the pipeline still needs an assertion that distinguishes the expected result from a failure.

Keep migrations and backup operations in the tooling designed for those tasks. A healthy WhoDB process does not prove that a migration created the required table or that the fixture has the expected values.

Reproduce a failing check#

Retain redacted structured output with the job's fixture and migration versions. Connect the browser app to the disposable database when you need to inspect the failed state interactively. Save the query that explains the failure so the same check can run in the next job.

Continue with Testing workflows.