#!/usr/bin/env bash
# =============================================================================
# entrypoint.sh — TRM directus image boot flow
#
# Apply order (non-negotiable, per ROADMAP design rule #3):
#   1. db-init runner (PRE-schema) — applies db-init/*.sql migrations against
#      Postgres. These are migrations for tables Directus does NOT manage
#      (positions hypertable, faulty column, future PostGIS extension).
#   2. Directus schema apply — applies snapshots/schema.yaml so the running
#      schema matches what's in git. This creates the Directus-managed
#      tables (organizations, events, entries, etc.). No-op if schema.yaml
#      doesn't exist or is empty.
#   3. db-init runner (POST-schema) — applies db-init-post/*.sql migrations.
#      These are constraints/indexes on Directus-managed tables that the
#      snapshot YAML format cannot capture (composite UNIQUE constraints).
#      Must run AFTER schema-apply because the tables don't exist before then.
#   4. Directus bootstrap — idempotent first-boot setup (admin user, system
#      tables). Already-bootstrapped instances treat this as a fast no-op.
#   5. Directus start under pm2-runtime — the upstream image's actual run
#      pattern. pm2 provides crash recovery and signal handling inside the
#      container.
#
# Any failure halts boot (set -euo pipefail). Operators see a clear log line
# in container output telling them which step failed.
# =============================================================================

set -euo pipefail

log() {
  printf '[entrypoint] %s\n' "$*"
}

log "step 1/5: db-init (pre-schema)"
/directus/scripts/apply-db-init.sh

log "step 2/5: directus schema apply"
/directus/scripts/schema-apply.sh

log "step 3/5: db-init (post-schema)"
DB_INIT_DIR=/directus/db-init-post /directus/scripts/apply-db-init.sh

log "step 4/5: directus bootstrap"
node /directus/cli.js bootstrap

log "step 5/5: directus start (pm2-runtime)"
exec pm2-runtime start /directus/ecosystem.config.cjs