Make DATABASE_URL configurable for dev and test

[T0ha]

Summary

• Allow overriding the hardcoded Postgres connection for dev/test via the DATABASE_URL environment variable, mirroring the existing prod behavior.
• config/dev.exs / config/test.exs defaults are left completely untouched and remain in effect whenever DATABASE_URL is unset.
• Documented the new variable in the README under a new "Database Configuration" section.

Implementation notes

• config/runtime.exs already runs for every Mix env (dev/test/prod), so the new override is a small guarded block: if config_env() in [:dev, :test] + if database_url = System.get_env("DATABASE_URL"), setting config :bodhi, Bodhi.Repo, url: database_url.
• Ecto's URL-merge logic makes the parsed URL win over any leftover hardcoded keys, so no changes were needed to pool_size, the sandbox pool config, etc.
• Added test/config/runtime_test.exs, which re-evaluates config/runtime.exs via Config.Reader.read!/2 for :dev and :test, asserting: no override when DATABASE_URL is unset, and the URL is applied when it is set.

Verification (see note below on sandbox limitations)

• mix compile — no new warnings (one pre-existing, unrelated warning in lib/bodhi/tg_webhook_handler.ex present on main too)
• New tests in test/config/runtime_test.exs pass (4/4)
• App boots successfully under mix run with the new config in place
• mix dialyzer — passes with 0 errors
• mix format — no changes needed
• mix credo --strict — no new issues (pre-existing issues only, in files untouched by this PR)
• Full mix test suite — could not be run in this environment: the sandbox has no reachable Postgres instance (no Docker, no local postgres binary, no sudo to install one), so mix ecto.create fails before any DB-backed test can run. This reproduces identically on unmodified main, confirming it's a pre-existing environment limitation, not a regression from this change. Please run the full suite in CI/locally where Postgres is available.

Test plan

• CI runs mix test against the docker-compose Postgres service and confirms all DB-backed tests still pass
• Manually set DATABASE_URL locally for dev/test and confirm the app connects to the alternate database
• Confirm leaving DATABASE_URL unset still connects to the existing default dev/test databases

🤖 Generated with Claude Code

[claude]

Review: Make DATABASE_URL configurable for dev and test

Overall this is a small, well-scoped change that mirrors the existing prod pattern in config/runtime.exs, and it comes with new tests and README docs. A few things worth a look before merging:

Potential issue: collision with the existing .env / compose.yml

The repo already has a root .env used by compose.yml (env_file: .env for both the postgres and web services):

POSTGRES_HOST=postgres
DATABASE_URL="postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}/${POSTGRES_DB}"

That DATABASE_URL targets the Docker-internal hostname postgres, which is only resolvable inside the compose network — it's meant for the containerized web service (running with MIX_ENV=prod), not for a host-run mix phx.server/mix test. The intended local flow today is docker compose up postgres (exposed on 127.0.0.1:5433, matching the hardcoded config/dev.exs/config/test.exs) + host-run mix commands with no env var needed.

If a developer ever exports this .env into their shell (e.g. set -a; source .env to grab POSTGRES_PASSWORD for psql, or a future direnv change that loads it like the .envrc pattern already documented in the README for OPENROUTER_API_KEY/GEMINI_API_KEY), mix phx.server/mix test run on the host would now silently redirect from the working localhost:5433 to the unreachable postgres hostname — with no obvious link back to .env being the cause. Worth either calling out this caveat explicitly in the new README section, or considering a distinct variable name for the dev/test override so it can't collide with the compose-oriented DATABASE_URL already living in .env.

Test coverage gap

test/config/runtime_test.exs re-evaluates config/runtime.exs in isolation via Config.Reader.read!/2. Since only runtime.exs is evaluated (not config/config.exs + config/dev.exs/test.exs), the assertions really only confirm that runtime.exs itself does/doesn't add a Bodhi.Repo key — they don't exercise the actual merge with the compile-time defaults (pool_size, hostname, the Ecto.Adapters.SQL.Sandbox pool setting for test, etc.). That merge behavior is exactly what the PR description leans on ("no changes were needed to pool_size, the sandbox pool config, etc."), so it'd be good to add a test that merges the compile-time env config with the runtime override (or actually calls Bodhi.Repo.config()/starts the repo) to verify those keys really do survive the override, rather than relying on it being implied.

Minor/non-blocking: setting DATABASE_URL for :test will fully replace the database: key from config/test.exs, including the #{System.get_env("MIX_TEST_PARTITION")} suffix used for CI test parallelism. That's an inherent consequence of a full-URL override and probably fine, but a one-line note in the README would save someone a confused debugging session if they combine DATABASE_URL with partitioned test runs.

What looks good

• Change is minimal and consistent with the existing prod block's style in the same file.
• No hardcoded secrets introduced; README example uses a placeholder.
• on_exit properly restores the original DATABASE_URL and the test module is async: false, avoiding races on the shared process env.
• config/dev.exs/config/test.exs are untouched, so behavior is unchanged when the var isn't set — confirmed by reading both files.

No blocking correctness bugs found in the config/runtime.exs logic itself.