e01abfef27
CI dry-run revealed an architectural ordering bug: db-init/004 and
db-init/005 ALTER TABLE the Directus-managed tables (organization_users,
events, etc.), but db-init runs BEFORE schema-apply creates those
tables. On a fresh CI Postgres this fails with "relation does not
exist." Local dev never tripped this because we'd created the tables
via MCP first.
Fix: introduce a post-schema migration phase. Two db-init runs in the
entrypoint, with schema-apply in between:
1. apply-db-init.sh db-init/ → positions hypertable + faulty
column (tables Directus does
NOT manage)
2. schema-apply.sh → creates Directus-managed tables
from snapshots/schema.yaml
3. apply-db-init.sh db-init-post/ → composite UNIQUE constraints on
the Directus-managed tables
4. directus bootstrap
5. directus start
Files moved:
db-init/004_junction_unique_constraints.sql →
db-init-post/001_junction_unique_constraints.sql
db-init/005_event_participation_unique_constraints.sql →
db-init-post/002_event_participation_unique_constraints.sql
Each ALTER TABLE in the post-schema migrations is now wrapped in a
pg_constraint existence guard for idempotency. This handles the dev DB
where the constraints already exist (from the original 004/005 runs +
the manual psql recovery during task 1.5's destructive-apply
incident). Old 004/005 rows in migrations_applied become orphans —
harmless.
Updates:
- Dockerfile: COPY db-init-post into the image
- entrypoint.sh: 4-step → 5-step flow with the post-schema run between
schema-apply and bootstrap
- .gitea/workflows/build.yml: dry-run chains all three pre-boot scripts
(pre-schema → schema-apply → post-schema); path filter includes
db-init-post/**
- Task specs 1.4 and 1.5 Done sections: updated to reference the new
db-init-post/ path (db-init/004 → db-init-post/001, etc.)
The reusable runner script (apply-db-init.sh) didn't need to change —
it already accepts DB_INIT_DIR and uses just the basename for the
guard-table key. The two phases share migrations_applied; filenames
don't collide because pre-schema and post-schema use distinct
descriptive names.
Phase 1 is still "done" — this is a Phase 1 architectural correction
exposed by the CI dry-run, not a new task.
55 lines
2.4 KiB
Docker
55 lines
2.4 KiB
Docker
# syntax=docker/dockerfile:1.7
|
|
#
|
|
# TRM directus service image.
|
|
#
|
|
# Single-stage build for Phase 1. A multi-stage build (with a Node builder for
|
|
# extensions) lands in Phase 5 when TypeScript extensions are introduced.
|
|
#
|
|
# Artifacts baked into the image at build time:
|
|
# /directus/snapshots/ — schema.yaml (generated)
|
|
# /directus/db-init/ — pre-schema migrations (positions hypertable etc.)
|
|
# /directus/db-init-post/ — post-schema migrations (constraints on Directus
|
|
# managed tables; applied AFTER schema-apply)
|
|
# /directus/scripts/ — shell helpers (apply-db-init.sh, schema-apply.sh)
|
|
# /directus/extensions/ — TypeScript extensions (Phase 5)
|
|
# /directus/entrypoint.sh — boot wrapper (5-step flow: pre-schema db-init →
|
|
# schema apply → post-schema db-init → bootstrap → start)
|
|
#
|
|
# No bind mounts of these directories in compose.dev.yaml — the image is the
|
|
# source of truth. Reproducible across local, CI, and production environments.
|
|
|
|
FROM directus/directus:11.17.4
|
|
|
|
# Switch to root only for the setup steps; Directus's upstream image already
|
|
# drops to a non-root user — we preserve that for runtime.
|
|
USER root
|
|
|
|
# Install bash + postgresql-client.
|
|
# bash: scripts/apply-db-init.sh (task 1.2) uses bash-specific
|
|
# features (associative arrays, [[ ]], mapfile,
|
|
# BASH_REMATCH). Alpine ships ash via BusyBox, not bash —
|
|
# without this the script fails at line 1 (shebang) or
|
|
# line 69 (array declaration) depending on how it's run.
|
|
# postgresql16-client: provides psql + pg_isready, required by the db-init
|
|
# runner.
|
|
RUN apk add --no-cache bash postgresql16-client
|
|
|
|
# ---- Copy baked-in artifacts ----
|
|
# Each COPY is conditional on the directory existing at build time.
|
|
# .gitkeep files ensure the directories always exist so COPY never fails.
|
|
COPY snapshots/ /directus/snapshots/
|
|
COPY db-init/ /directus/db-init/
|
|
COPY db-init-post/ /directus/db-init-post/
|
|
COPY scripts/ /directus/scripts/
|
|
COPY extensions/ /directus/extensions/
|
|
COPY entrypoint.sh /directus/entrypoint.sh
|
|
|
|
# Ensure the entrypoint is executable inside the image regardless of the host
|
|
# filesystem's permission bits.
|
|
RUN chmod +x /directus/entrypoint.sh
|
|
|
|
# Drop back to the non-root user the upstream image uses.
|
|
USER node
|
|
|
|
ENTRYPOINT ["/directus/entrypoint.sh"]
|