One-time tool: dumps the local dev Postgres, scp's it to the server,
and restores it into the remote postgres container over SSH - drops
and recreates the target database, so it prompts for an explicit YES
before touching the remote side. Connection details are placeholders
(SSH_USER/SSH_HOST/etc.) filled in via env vars or direct edits, never
committed with real values.
upsertGoogleUser's nested channels.create (the auto-provisioning path
for a brand new team's first Google login) never set
supplementalVideoIds, a required String[] column with no DB default
(dropped intentionally in 20260608000002 to match the Prisma schema).
channel-import.service.ts already sets it explicitly on its create path
- this path was just missed, and nothing had exercised a real first
login against Postgres until now.
api container crashed on boot: Cannot find module '/app/dist/main.js'.
Root cause: tsconfig.json had no rootDir, and prisma/make-admin.ts (run
separately via ts-node, never part of the Nest build) was swept into
the nest build compilation since there was no exclude either - so tsc
inferred the output root as the project root and nested everything
under dist/src/ instead of the flat dist/main.js the Dockerfile,
package.json scripts, and compose's worker command all assume.
Also excludes tsconfig.tsbuildinfo from the Docker build context - a
stale local incremental-build cache file was leaking in via `COPY . .`
(only dist/node_modules were dockerignored) and made nest build skip
emitting .js files entirely on a from-scratch container build once the
rootDir fix invalidated its cached signature.
Portainer's compose up blocks on frontend's api: condition:
service_healthy dependency and, on timeout, tears down everything it
just created - so an unhealthy api container never stuck around long
enough to pull logs from. Relaxed to service_started (frontend doesn't
need api ready at container-start), and gave the api healthcheck more
runway (60s start_period, 10 retries @ 10s) in case it's just slow to
boot rather than crashing.
The external network on the target server is named "proxy", not
traefik-network as originally assumed - deploy was failing with
"network traefik-network not found". Updated the compose file and
both the infra README and vault deployment doc to match.
pull_policy: always on the four studioflow services (migrate, api,
worker, frontend) so redeploying the stack in Portainer actually fetches
the latest pushed image instead of reusing a stale local layer for the
mutable `latest`/IMAGE_TAG reference. Third-party pinned images
(postgres, redis) are left on default pull behavior.
migrate/api/worker/frontend now reference
git.devils.zone/devil/youtube-studio-flow-{backend,frontend}:\${IMAGE_TAG}
instead of building on the deploy host. Adds scripts/build-and-push.sh
to build+tag (git short SHA + latest) and push both images from a dev
machine, and updates infrastructure/README.md with the pull-based
deploy sequence.
next build runs ESLint + full type-check and fails on errors (not just
warnings) - the production build was broken. Fixes: unused imports/vars,
any-typed diff/preference lookups replaced with the actual union/Record
types, ternary-as-statement flagged by no-unused-expressions, unescaped
JSX entities, a UserPreferences interface missing two fields the video
editor already reads/writes at runtime, and an import of
ColumnVisibilityState which @tanstack/react-table does not export
(the real name is VisibilityState).
Adds the git-workflow skill (Conventional Commits, auto-commit/push
policy, changelog process), CHANGELOG.md seeded from history, and
scripts/generate-changelog.sh to group commits by type. PRs remain
manual by design.
devil