fix(ci): stop Postgres state-bleed across CI runs (#277) #299

Merged

james merged 2 commits from 277-postgres-ci-state-bleed into main 2026-06-26 23:04:10 +00:00

Conversation 1 Commits 2 Files changed 3 +25 -56

james commented 2026-06-26 22:38:03 +00:00

Owner

Copy link

Closes #277.

Problem

The self-hosted Forgejo act_runner reuses the Postgres service container's
data volume across CI runs, so a table created by one PR's run (e.g. #269's
organization_key_people) is still physically present at the start of the
next run. When a PR is stale across a table-adding migration, the test
teardown's hardcoded KYSELY_TABLES drop list doesn't know about the orphan
table, its FK blocks the people drop, and all 15 Postgres suites fail at
apps/api/tests/db/_engines.ts. This is the #259-family failure that bit PR
#270.

Both fixes from the ticket are applied (defense-in-depth):

Fix 1 — tmpfs the Postgres data dir (CI)

.forgejo/workflows/pr.yml: the test job's postgres service now mounts
--tmpfs /var/lib/postgresql/data, so the data dir lives in RAM and is fresh
on every container start. initdb re-runs clean each time, making the
runner's volume reuse harmless. Fixes the visible symptom.

Fix 2 — derive the teardown drop-list at runtime (test infra)

apps/api/tests/db/_engines.ts: the hardcoded KYSELY_TABLES array is gone.
The Postgres engine setup now queries information_schema.tables (public
schema, base tables) and drops each with CASCADE. FK ordering no longer
matters, and no KYSELY_TABLES edit is ever needed when a migration adds a
table (#259). A database left orphaned by a previous run still tears down
cleanly even if the infra side regresses. Also drops the stale
KYSELY_TABLES reference in 018_people.ts's down-migration comment.

This directly satisfies acceptance criterion 2, so the alternative CI
drift-assertion is not needed.

Verification (local, Docker Postgres)

• Full suite against Postgres: 953 passed.
• Injected the #277 orphan scenario (people + a dependent FK table) into the
  DB, re-ran: 953 passed — teardown handles the orphan (pre-fix this
  failed at the people drop).
• sqlite-only run (no TEST_POSTGRES_URL): 786 passed / 167 skipped,
  unchanged.
• tsc --noEmit and actionlint clean.

End-to-end acceptance (CI-only): a PR branched off a stale base across a
table-adding migration should now go green without a rebase.

🤖 Generated with Claude Code

Closes #277. ## Problem The self-hosted Forgejo `act_runner` reuses the Postgres service container's data volume across CI runs, so a table created by one PR's run (e.g. #269's `organization_key_people`) is still physically present at the *start* of the next run. When a PR is stale across a table-adding migration, the test teardown's hardcoded `KYSELY_TABLES` drop list doesn't know about the orphan table, its FK blocks the `people` drop, and all 15 Postgres suites fail at `apps/api/tests/db/_engines.ts`. This is the #259-family failure that bit PR #270. Both fixes from the ticket are applied (defense-in-depth): ## Fix 1 — tmpfs the Postgres data dir (CI) `.forgejo/workflows/pr.yml`: the `test` job's `postgres` service now mounts `--tmpfs /var/lib/postgresql/data`, so the data dir lives in RAM and is fresh on every container start. `initdb` re-runs clean each time, making the runner's volume reuse harmless. Fixes the visible symptom. ## Fix 2 — derive the teardown drop-list at runtime (test infra) `apps/api/tests/db/_engines.ts`: the hardcoded `KYSELY_TABLES` array is gone. The Postgres engine setup now queries `information_schema.tables` (public schema, base tables) and drops each with `CASCADE`. FK ordering no longer matters, and no `KYSELY_TABLES` edit is ever needed when a migration adds a table (#259). A database left orphaned by a previous run still tears down cleanly even if the infra side regresses. Also drops the stale `KYSELY_TABLES` reference in `018_people.ts`'s down-migration comment. This directly satisfies acceptance criterion 2, so the alternative CI drift-assertion is not needed. ## Verification (local, Docker Postgres) - Full suite against Postgres: **953 passed**. - Injected the #277 orphan scenario (`people` + a dependent FK table) into the DB, re-ran: **953 passed** — teardown handles the orphan (pre-fix this failed at the `people` drop). - sqlite-only run (no `TEST_POSTGRES_URL`): **786 passed / 167 skipped**, unchanged. - `tsc --noEmit` and `actionlint` clean. End-to-end acceptance (CI-only): a PR branched off a stale base across a table-adding migration should now go green without a rebase. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james added 2 commits 2026-06-26 22:38:03 +00:00

fix(ci): tmpfs Postgres service data dir (#277) ... e726a9a240

The self-hosted Forgejo act_runner reuses the Postgres service
container's data volume across runs, so a table created by one PR's run
is still present at the start of the next. A PR stale across a
table-adding migration then fails teardown on the orphan's FK. Mount the
data dir as tmpfs so every run starts from an empty database.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

test(db): derive Postgres teardown drop-list at runtime (#277) ... 0c24923b46

Replace the hardcoded KYSELY_TABLES drop list with a runtime query over
information_schema.tables plus DROP ... CASCADE. FK ordering no longer
matters and no edit is needed when a migration adds a table (#259), so a
database left orphaned by a previous CI run tears down cleanly even
without the tmpfs fix.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

forgejo-actions commented 2026-06-26 22:47:47 +00:00

Copy link

📊 Test coverage

Patch coverage: no testable lines changed.

Overall (app/, lib/, db/, excluding UI per ADR-0019):

Metric	Value	Soft target
Lines	81.6% ✅	≥ 50%
Branches	72.8% ⚠️	≥ 75%
Functions	91.1%	informational

Soft thresholds per ADR-0019. Coverage is informational and does not block merge.

<!-- coverage-comment --> ## 📊 Test coverage **Patch coverage:** no testable lines changed. **Overall** (`app/`, `lib/`, `db/`, excluding UI per ADR-0019): | Metric | Value | Soft target | |---|---|---| | Lines | 81.6% ✅ | ≥ 50% | | Branches | 72.8% ⚠️ | ≥ 75% | | Functions | 91.1% | informational | Soft thresholds per [ADR-0019](docs/adr/0019-coverage-soft-targets.md). Coverage is informational and does not block merge.

james merged commit 0dffb2661e into main 2026-06-26 23:04:10 +00:00

james deleted branch 277-postgres-ci-state-bleed 2026-06-26 23:04:11 +00:00

james referenced this pull request from a commit 2026-06-26 23:04:12 +00:00

Merge pull request 'fix(ci): stop Postgres state-bleed across CI runs (#277)' (#299) from 277-postgres-ci-state-bleed into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

area:auth

Authentication and authorization

  

area:ci

Forgejo Actions, build, test, security, release

  

area:db

Database abstraction, migrations, persistence

  

area:infra

Containerization, deployment, foundational tooling

  

area:native

React Native app (Android + Linux Flatpak)

  

area:pwa

PWA / web frontend

  

area:service

Backend service, API routes, persistence

  

epic

High-level tracker; links several feature tickets

  

feature

A user-facing feature

  

foundation

Foundational work that other tickets build on

No labels

area:auth

area:ci

area:db

area:infra

area:native

area:pwa

area:service

epic

feature

foundation

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

james/carol!299

No description provided.