Commit Graph

2 Commits

Author SHA1 Message Date
julian ef8bd91d77 Reorder boot: bootstrap before schema-apply (and harden schema-apply)
Second CI dry-run failure exposed two more issues:

1. Schema-apply runs against a fresh Postgres → fails with "Directus
   isn't installed on this database. Please run 'directus bootstrap'
   first."  Bootstrap is what creates Directus's system tables; schema
   apply requires those tables to exist.  Local dev never tripped this
   because bootstrap had been done in earlier sessions.

2. `node cli.js schema apply` printed an ERROR but exited 0 in the
   not-installed case.  schema-apply.sh trusted the exit code,
   reported "schema apply complete," and the chain continued — until
   the post-schema migration tried to ALTER TABLE on user tables that
   never got created.

Fixes:

- entrypoint.sh: reorder steps from
    pre-schema → schema-apply → post-schema → bootstrap → start
  to
    pre-schema → bootstrap → schema-apply → post-schema → start
  Bootstrap is idempotent ("Database already initialized, skipping
  install" on warm DB) so adding it earlier costs nothing on warm
  boots and unblocks fresh boots.

- .gitea/workflows/build.yml: dry-run chain updated to mirror the new
  entrypoint order. Bootstrap is now part of the pre-boot validation,
  not skipped for speed. CI dry-run now genuinely covers the same path
  the production entrypoint takes (minus the final pm2-runtime step,
  which doesn't add validation value).

- scripts/schema-apply.sh: defense in depth. After the apply call
  succeeds (exit 0), grep the output for ' ERROR: ' and fail loudly if
  found. Catches the silent-failure pattern Directus's CLI exhibits
  when bootstrap hasn't run. Error message names the likely cause
  (schema-apply before bootstrap) for fast operator triage.

This is the second Phase 1 architectural correction exposed by the CI
dry-run gate. The gate is paying for itself in the very first PR it
runs against.
2026-05-02 10:51:39 +02:00
julian e22d9d489a Tasks 1.6 + 1.7 — schema tooling + real entrypoint flow
Two parallel tasks landing together. The boot pipeline is now wired
end-to-end: db-init → schema apply → directus bootstrap → pm2-runtime.
Live-verified by booting a fresh compose stack to a serving Directus
admin UI on :8055.

Task 1.6 — snapshot tooling:
- scripts/schema-snapshot.sh — host-side, dev-time. Verifies docker
  is on PATH and the directus compose service is running, runs
  `node /directus/cli.js schema snapshot --yes` inside the container,
  copies the YAML out to ./snapshots/schema.yaml. Used after admin-UI
  schema changes to capture the new state for git commit.
- scripts/schema-apply.sh — image-side, boot-time. Reads
  /directus/snapshots/schema.yaml, runs a dry-run preview, then
  applies. Gracefully skips when the snapshot is absent or whitespace-
  only (Phase 1 first-boot path before tasks 1.4/1.5 produce
  collections). SNAPSHOT_PATH env var override for CI flexibility.
- snapshots/README.md — lifecycle doc; warns against hand-editing.

Task 1.7 — real entrypoint flow:
- entrypoint.sh rewritten from Phase 1.1's placeholder to the
  4-step boot per ROADMAP design rule #3:
    1/4 db-init          → /directus/scripts/apply-db-init.sh
    2/4 schema apply     → /directus/scripts/schema-apply.sh
    3/4 directus bootstrap → node /directus/cli.js bootstrap
    4/4 directus start   → exec pm2-runtime start ecosystem.config.cjs
  set -euo pipefail halts boot on any step's non-zero exit. Each step
  emits a [entrypoint] log marker so an operator reading container
  logs sees which step failed.

Bug found and fixed during live verification:
- Both 1.6 scripts initially called bare `directus schema ...` as if
  the CLI were on PATH. Upstream directus/directus:11.17.4 does NOT
  expose `directus` on PATH — invocation is via `node /directus/cli.js`,
  same pattern as the entrypoint's bootstrap step. Both scripts
  corrected. Also added -T to docker compose exec in schema-snapshot.sh
  so the script works in non-TTY contexts (CI).

Phase 5 follow-up (non-blocking) flagged in 07's Done section: Directus
warns "Collection 'positions' doesn't have a primary key column and
will be ignored". The positions table uses UNIQUE INDEX (device_id, ts)
matching processor's pattern, not a PK constraint. Means positions is
not auto-registered as a Directus collection — fine for Phase 1, but
the operator faulty-flag workflow will need a custom endpoint or
manual collection registration in Phase 5.

ROADMAP marks 1.6 + 1.7 done. Phase 1 progress: 5/9 tasks complete
(1.1, 1.2, 1.3, 1.6, 1.7); 1.4, 1.5, 1.8, 1.9 remain.
2026-05-02 09:40:53 +02:00