feat(docker): production image and Docker Hub publishing - #187
Merged
Conversation
The only image so far was the development one: it bind-mounts the source and runs `next dev`, so it cannot be distributed. This adds a real production image and the workflow that publishes it. The build is multi-stage. Next.js now emits a standalone server bundle, so the runner carries the traced runtime only instead of the full node_modules. It runs as the unprivileged `node` user and exposes a healthcheck against /api/health. Migrations are applied by the entrypoint before the server starts. The Prisma CLI could not simply be copied out of the app dependencies (its config loader pulls packages that the Next.js trace drops), so it gets its own install tree under /opt/prisma, pinned to the lockfile version. Set RUN_MIGRATIONS=false when a separate job owns the schema. The former Dockerfile becomes Dockerfile.dev and compose.yml points at it, so the local stack is unchanged. Verified by building the image and running it against the local database: migrations applied, /api/health returns db up, /login serves 200.
Without a gate, anyone able to push a `v*` tag triggers an immediate public image push. The job now runs in the `dockerhub` environment, which requires a manual approval and is restricted to `main`, `develop` and release tags. The Docker Hub credentials move to that environment as well.
feat(docker): add production image and Docker Hub publishing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promotion of
developtomain. The scope is the Docker work from #186, nothing else is pending.What lands
Dockerfilebecomes the production image: multi-stage build, Next.js standalone server, unprivilegednodeuser, healthcheck on/api/health.Dockerfile.dev;compose.ymlpoints at it, so the local stack is unchanged.docker/entrypoint.shrefuses to start withoutDATABASE_URL, appliesprisma migrate deploy, then execs the server.RUN_MIGRATIONS=falseskips the migration step when a separate job owns the schema..github/workflows/docker-publish.ymlbuilds and pushes onv*.*.*tags, plus anedgetag on manual dispatch. The job runs in the protecteddockerhubenvironment: manual approval required, restricted tomain,developand release tags.Why this promotion now
GitHub only exposes
workflow_dispatchfor workflows present on the default branch. Landing this onmainmakes the publish job dispatchable, so the credentials and the approval gate can be validated against a throwawayedgetag instead of during a real release.Verification
The image was built locally and run against the development database: 30 migrations applied,
/api/healthreturns{"status":"ok","db":"up"},/loginserves 200. All 15 checks passed on #186.