The build:server script (esbuild) expects server.ts at the working
directory root, but the Dockerfile only copied the server/ directory.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Merge typecheck + lint into a single `check` job to eliminate one full
job lifecycle and one npm ci invocation (~2-4 min savings)
- Remove `apt-get install docker.io` step — Docker CLI and buildx v0.23.0
are now pre-installed in the custom brackt-runner:latest image
- Reorder Dockerfile build-env COPY layers so node_modules and config
files are copied before source, improving registry cache hit granularity
- Expand .dockerignore to exclude .forgejo, .git, docs, plans, cypress,
logs, .env files, and tsbuildinfo files from the build context
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
## Summary
- **Dockerfile layer caching**: `development-dependencies-env` now copies only `package.json`/`package-lock.json` before `npm ci` (was `COPY . /app`), so the npm install layer is cached on every code-only commit instead of rebuilt from scratch
- **Skip QEMU**: `platforms: linux/amd64` added to `build-push-action`, cutting `setup-buildx-action` from ~5 min to ~30 sec
- **npm cache in CI jobs**: Manual `actions/cache@v3` blocks (copy-pasted 3×) replaced with `actions/setup-node@v4` + `cache: 'npm'`, which handles path/key/restore automatically and pins Node 20 explicitly
- **Harden `.npmrc`**: Switched from `COPY .npmrc` to `--mount=type=secret,id=npmrc` in both `npm ci` stages — the file is available during install but never written into a Docker layer, so it cannot leak through the registry build cache regardless of future contents
## Expected timing
| Step | Before | After (code change) |
|---|---|---|
| Setup buildx | ~5 min | ~30 sec |
| Build + push | ~5 min | ~1-2 min |
| Deploy (docker pull) | ~5 min | ~1-2 min |
| **Total** | **~15 min** | **~3-5 min** |
## Test plan
- [ ] Push a code-only commit to main — confirm `setup-buildx-action` logs ~30s (no QEMU), Docker build shows `CACHED` for npm install layers, build+push completes in ~1-2 min
- [ ] Check deploy job — `docker compose pull` should show most layers as `Already exists`
- [ ] Push a commit that changes `package.json` — confirm npm layer correctly re-runs (not cached)
- [ ] Confirm deployed app is functional
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Chris Parsons <chrisparsons1127@gmail.com>
Reviewed-on: #59
* Use Docker Compose init service pattern for database migrations
Replaces the fragile double-migration approach (server.ts startup +
drizzle-kit CLI in CI) with a one-shot migrate service in Docker Compose
that the app depends on via condition: service_completed_successfully.
- Add scripts/migrate.mjs: programmatic drizzle-orm migration (uses
production deps, not drizzle-kit which is devOnly and absent from image)
- Dockerfile: copy scripts/ into image, remove drizzle.config.ts (only
needed by drizzle-kit CLI)
- server.ts: remove runMigrations() entirely; migrations are now handled
by the migrate container before the app starts
- deploy.yml: remove explicit docker run migration step; replace sleep 10
health check with a poll loop and explicit migrate exit-code check
Production server's docker-compose.yaml needs a one-time manual update
to add the migrate service — see plan for exact config.
https://claude.ai/code/session_01ReaqH3o9NVH4QU4qE9WMMQ
* Move drizzle-kit to devDependencies; use docker compose wait in deploy
drizzle-kit is a dev-only tool (schema generation and local migrations).
Now that production migrations run via the programmatic drizzle-orm API
in the migrate init container, drizzle-kit has no runtime role.
Also replaces the polling health check loop with docker compose wait,
which blocks until the migrate service exits and returns its exit code
cleanly — no sleep or manual status inspection needed.
https://claude.ai/code/session_01ReaqH3o9NVH4QU4qE9WMMQ
---------
Co-authored-by: Claude <noreply@anthropic.com>
* Update claude.md to push more tests.
* Archiving old plans.
* fix: run DB migrations programmatically on server startup
Replace unreliable drizzle-kit CLI migration with drizzle-orm's built-in
migrator running in the server process before accepting connections. This
ensures migrations are always applied on deploy and fails fast if they error.
- Add runMigrations() to server.ts using drizzle-orm/postgres-js/migrator
- Skip migrations in development (handled manually via db:migrate)
- Add DATABASE_URL guard with a clear error message
- Remove start:production script (now identical to start)
- Update Dockerfile CMD to use npm run start
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
