Files
directus/.gitea/workflows/build.yml
T
julian e01abfef27 Split db-init into pre-schema and post-schema phases
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.
2026-05-02 10:48:06 +02:00

149 lines
6.9 KiB
YAML

name: Build directus image
on:
push:
branches: [main]
paths:
- 'snapshots/**'
- 'db-init/**'
- 'db-init-post/**'
- 'extensions/**'
- 'scripts/**'
- 'entrypoint.sh'
- 'Dockerfile'
- '.gitea/workflows/build.yml'
workflow_dispatch:
jobs:
build-and-publish:
runs-on: ubuntu-22.04
# ---------------------------------------------------------------------------
# Throwaway Postgres for the dry-run boot step.
#
# Image: pinned to the same concrete tag used in compose.dev.yaml — NOT the
# floating :pg16-latest alias (which does NOT exist on Docker Hub).
#
# PGDATA: the timescaledb-ha image initialises at /home/postgres/pgdata/data;
# the healthcheck uses pg_isready, which doesn't depend on the PGDATA path.
#
# Port mapping: 15432:5432 — host port 15432 is the conventional
# Postgres-second-instance port. We deliberately do NOT use 5432 on the
# runner because the runner host typically has another Postgres on 5432
# (dev stack, stage instance) which would cause a port-allocation collision.
# The dry-run docker run uses --network host so DB_HOST=localhost reaches
# the service on the runner's loopback at port 15432.
# ---------------------------------------------------------------------------
services:
postgres:
image: timescale/timescaledb-ha:pg16.6-ts2.17.2-all
env:
POSTGRES_USER: directus
POSTGRES_PASSWORD: directus
POSTGRES_DB: directus
ports:
- '15432:5432'
options: >-
--health-cmd "pg_isready -U directus -d directus"
--health-interval 5s
--health-timeout 5s
--health-retries 20
steps:
- name: Checkout
uses: actions/checkout@v4
# -------------------------------------------------------------------------
# Build the image locally (trm-directus:ci).
#
# We use a plain `docker build` rather than docker/build-push-action because
# we need the image available in the *local Docker daemon* for the subsequent
# `docker run` dry-run step. docker/build-push-action with the
# docker-container Buildx driver exports into a separate buildkitd cache not
# accessible to `docker run`.
# -------------------------------------------------------------------------
- name: Build image
run: docker build -t trm-directus:ci .
# -------------------------------------------------------------------------
# Dry-run boot — the gate that protects the registry from broken images.
#
# Runs the pre-boot script chain (apply-db-init.sh → schema-apply.sh →
# apply-db-init.sh against db-init-post) against the throwaway Postgres
# service above. Mirrors the entrypoint's first three steps.
# Intentionally does NOT run `directus bootstrap` or `directus start` —
# that would require waiting for the HTTP server to come up, which adds
# minutes and tests nothing new.
#
# --network host: the service container is mapped on 127.0.0.1:5432; the
# docker run container sees it as localhost:5432 only when host networking
# is used. Without --network host, the container would be in a separate
# bridge network and could not reach the service by name or IP.
#
# --entrypoint bash: overrides /directus/entrypoint.sh so we execute only
# the script chain, not the full pm2-runtime boot.
#
# Required Directus env vars: DB_CLIENT + connection params are mandatory
# for `node cli.js schema apply`. KEY + SECRET are required by Directus's
# env initialisation even when only the schema subcommand is invoked.
# ADMIN_EMAIL + ADMIN_PASSWORD are included defensively (some Directus
# versions assert on them during CLI init). PUBLIC_URL silences the
# missing-public-url warning.
#
# If this step exits non-zero the workflow halts and the registry login /
# push steps are never reached — the broken image is never published.
# -------------------------------------------------------------------------
- name: Dry-run boot against throwaway Postgres
run: |
docker run --rm \
--network host \
--entrypoint bash \
-e DB_CLIENT=pg \
-e DB_HOST=localhost \
-e DB_PORT=15432 \
-e DB_USER=directus \
-e DB_PASSWORD=directus \
-e DB_DATABASE=directus \
-e KEY=ci-key-placeholder-not-secret \
-e SECRET=ci-secret-placeholder-not-secret \
-e ADMIN_EMAIL=ci@example.com \
-e ADMIN_PASSWORD=ci-password-not-secret \
-e PUBLIC_URL=http://localhost:8055 \
trm-directus:ci \
-c '/directus/scripts/apply-db-init.sh && /directus/scripts/schema-apply.sh && DB_INIT_DIR=/directus/db-init-post /directus/scripts/apply-db-init.sh && echo "dry-run ok"'
# -------------------------------------------------------------------------
# Registry login — runs only if the dry-run succeeded (default: workflow
# halts on non-zero exit, so reaching this step implies dry-run passed).
# -------------------------------------------------------------------------
- name: Login to Gitea registry
uses: docker/login-action@v3
with:
registry: git.dev.microservices.al
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
# -------------------------------------------------------------------------
# Tag and push two tags:
# :main — mutable; always points at the latest commit on main.
# :<sha> — immutable; pinned to this specific commit.
# The deploy stack can reference either; :main for rolling updates,
# :<sha> for pinned deployments that need explicit rollback control.
# -------------------------------------------------------------------------
- name: Tag and push
run: |
docker tag trm-directus:ci git.dev.microservices.al/trm/directus:main
docker tag trm-directus:ci git.dev.microservices.al/trm/directus:${{ github.sha }}
docker push git.dev.microservices.al/trm/directus:main
docker push git.dev.microservices.al/trm/directus:${{ github.sha }}
# -------------------------------------------------------------------------
# Optional Portainer redeploy webhook.
# Fires only when PORTAINER_WEBHOOK_URL secret is configured in the repo.
# If the secret is absent the condition evaluates false and the step is
# skipped — no error, no noise.
# -------------------------------------------------------------------------
- name: Trigger Portainer redeploy (optional)
if: ${{ secrets.PORTAINER_WEBHOOK_URL != '' }}
run: curl -fsS -X POST "${{ secrets.PORTAINER_WEBHOOK_URL }}"