Repository navigation
Build and publish the container image on push to main - #1
Merged
Merged
Conversation
Coolify compiles the application on the shared host on every deploy, which ties up CPU and disk for the other applications on the box. Move the build to GitHub Actions: publish.yaml builds the image, pushes it to GHCR, and then calls the Coolify deploy API for va-partners-test. docker-compose.yaml now references the published image and has no `build:` key — that absence is what keeps the build off the server. The build key moves to docker-compose.build.yaml, which CI overlays so PR runs still verify an image built from the branch rather than the published :latest. The NEXT_PUBLIC_NEXTAUTH_URL build arg is dropped. It was baked into the image and differs per environment, which would have tied one published build to one origin; it is also read nowhere in the application source, so removing it has no runtime effect. Migrations already run from docker-entrypoint.sh, so unlike the template there is no second image to fold in. Production is promoted by pinning IMAGE_TAG to a tested commit SHA rather than tracking :latest, so it runs the exact image verified on va-partners-test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CI builds the PR head; with squash merges the commit that lands on main is never exercised before its image is deployed. Run the production compose plus the ci MySQL overlay against the just-pushed tag with no build overlay, so the entrypoint's migrations run against the published image and the step proves it pulls and runs without anything being built. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Summary
Same setup as C4G/va-stats#4 and C4G/template#8: move the production image build off the shared Coolify host into GitHub Actions.
.github/workflows/publish.yaml(new) — on push tomain/workflow_dispatch: builds the image, pushesghcr.io/c4g/va-partners:latestand:<sha>, then triggers a Coolify deploy of va-partners-test.docker-compose.yaml— references the published image, nobuild:key. That absence is what stops Coolify from compiling on the server.docker-compose.build.yaml(new) — restores thebuild:key for local builds..github/workflows/ci.yaml— PR runs overlay the build file, so they still verify an image built from the branch.Dockerfile— drops theNEXT_PUBLIC_NEXTAUTH_URLbuild arg.README.md— deployment section replacing the stale "Deploy on Vercel" text.Simpler than the other two repos
docker-entrypoint.shalready runsprisma migrate deployat container start, so this repo was never building a second image.NEXT_PUBLIC_NEXTAUTH_URLis referenced nowhere in the application source — only inDockerfile,docker-compose.yamlandexample.env. No source file reads anyNEXT_PUBLIC_*at all. It was baked into the image and differs per environment, which would have tied one build to one origin, so dropping it makes the image environment-agnostic at zero runtime risk.va-partnersandva-partners-test, so no server-side change was needed (unlike va-stats, where it had to be switched off on the test app).Environments
va-partners-test.c4g.devva-partners-test(vz3iktyxmpi9i4bvmzsn2gs3)latest, deployed automatically on push to mainva-partners.c4g.devva-partners(o3e54e7xtuk12ghoxy07p6ot)IMAGE_TAGpinned to a commit SHA, deployed manuallyCOOLIFY_APP_UUIDrepository variable set to the test app. The deploy step skips itself if it orCOOLIFY_TOKENis missing.Verified locally with Docker
Built and booted the full stack (
docker-compose.yaml+docker-compose.ci.yaml+docker-compose.build.yaml):P1001→ retried), then all 13 migrations applied to the bundled MySQL and the app started.GET /api/health→{"status":"ok",...}, container reported healthy.va-partners*.c4g.devorigin baked anywhere in the server output, and the Prisma CLI is present at/usr/local/bin/prismafor the entrypoint.Note for anyone testing locally
The repo-root
.envis auto-loaded by Docker Compose for${VAR}substitution, and itsDATABASE_URLpoints at the remote staging database. A plaindocker compose uplocally therefore runsprisma migrate deployagainst staging rather than the bundled MySQL. Pass--env-file /dev/nullto force the bundled DB. CI is unaffected (no.envthere). Documented in the README.Follow-up required after the first run
The new GHCR package is created private. The Coolify host pulls anonymously (no
~/.docker/config.jsonon the server), soghcr.io/c4g/va-partnersmust be set to public — matching the existingghcr.io/c4g/*packages — or the first deploy will fail to pull.🤖 Generated with Claude Code