Add Docker support with multi-stage Dockerfile and compose config#111
Conversation
…ompose configuration, and updated dev scripts
|
Warning Review limit reached
More reviews will be available in 32 minutes. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a complete Docker-based local development setup: a multi-stage Dockerfile ( ChangesDocker Local Development Infrastructure
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying call-of-code with
|
| Latest commit: |
74b8849
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://4a64c099.call-of-code.pages.dev |
| Branch Preview URL: | https://fuck-local-dev.call-of-code.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
docker-compose.yml (1)
21-35: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueOptional: Simplify API_BASE_URL configuration — build arg is unused for runtime.
The
frontendservice passesAPI_BASE_URLboth as a build arg (line 27) and as a runtime environment variable (line 35). For Next.js, private env vars (those without theNEXT_PUBLIC_prefix) are not baked into the build — they are only used at runtime. The build arg is effectively ignored.Recommendation: Remove the build arg from the frontend service's
build.argssection. Keeping only the environment variable (line 35) is clearer and sufficient.♻️ Proposed simplification
build: context: . dockerfile: Dockerfile target: builder - args: - API_BASE_URL: ${API_BASE_URL:-http://coc-api:3000} image: coc-frontend:dev🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docker-compose.yml` around lines 21 - 35, The frontend service in the docker-compose.yml file currently passes API_BASE_URL as both a build argument (in the build.args section) and as a runtime environment variable. Since Next.js does not bake private environment variables (those without the NEXT_PUBLIC_ prefix) into the build, the build argument is redundant. Remove the API_BASE_URL build arg from the build.args section under the frontend service, while keeping the environment variable definition in the environment section, as this is where the value is actually used at runtime..github/workflows/docker-image.yml (2)
14-27: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winPin third-party actions to commit SHAs.
zizmorflags theactions/checkout,docker/login-action, anddocker/build-push-actionreferences as unpinned. Pinning to a full commit SHA (with the version as a trailing comment) protects against supply-chain tag-mutation attacks.For example:
uses: actions/checkout@<commit-sha> # v4 uses: docker/login-action@<commit-sha> # v3 uses: docker/build-push-action@<commit-sha> # v6🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/docker-image.yml around lines 14 - 27, The workflow file references third-party actions using version tags (v4, v3, v6) which are vulnerable to supply-chain attacks. Replace the version tags with full commit SHAs for the actions/checkout, docker/login-action, and docker/build-push-action actions, and add the version numbers as trailing comments to maintain clarity about which versions are being used.Source: Linters/SAST tools
26-27: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low valueConsider adding
docker/setup-buildx-actionbefore the build step.
docker/build-push-action@v6relies on Buildx; while it's preinstalled onubuntu-latest, explicitly runningdocker/setup-buildx-actionis the documented setup and enables features like build caching (cache-from/cache-to) to speed up CI.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/docker-image.yml around lines 26 - 27, The workflow is missing an explicit setup step for Docker Buildx before the docker/build-push-action@v6 step. Add a new step that uses docker/setup-buildx-action before the "Build and push Docker image" step to properly initialize Buildx and enable build caching features. This ensures the documented setup is followed and allows you to leverage cache optimization in subsequent build steps.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/docker-image.yml:
- Line 32: In the docker-image.yml workflow file, the tags property at line 32
currently specifies `callofcode07/callofcode:latest`, which does not align with
the image names referenced in docker-compose.yml (callofcode07/coc-api:latest
for the API service). Either update the published image name in the tags
property to match what the dev stack expects (callofcode07/coc-api), or add a
comment in the workflow explaining the intentional separation between the
published image and local development images. Additionally, replace the single
`:latest` tag with multiple tags including both a version-based immutable tag
(e.g., using git commit SHA or version number) and the `:latest` tag to enable
proper rollback and debugging of past deployments.
In `@Dockerfile`:
- Around line 1-41: In the runner stage of the Dockerfile, after setting ENV
NODE_ENV=production and before the EXPOSE instruction, create a non-root user
using RUN apk add --no-cache (if needed for your setup) and create the user with
appropriate commands. Then change the ownership of the /app directory to this
non-root user, and add a USER instruction to switch to that user before the CMD
instruction that runs npm run start. This ensures the application runs with
minimal privileges rather than as root.
- Around line 22-41: The runner stage in the Dockerfile does not declare the
API_BASE_URL environment variable, which is needed at runtime by the Next.js
application code in app/api/projects-with-members/route.ts and
app/achievements/page.tsx. After the ENV NODE_ENV=production line in the runner
stage (FROM node:20-alpine AS runner), add an ENV directive to declare
API_BASE_URL as an environment variable. This allows users to provide the value
at runtime via docker run -e API_BASE_URL=... or similar runtime mechanisms,
ensuring the variable is available when the container starts.
---
Nitpick comments:
In @.github/workflows/docker-image.yml:
- Around line 14-27: The workflow file references third-party actions using
version tags (v4, v3, v6) which are vulnerable to supply-chain attacks. Replace
the version tags with full commit SHAs for the actions/checkout,
docker/login-action, and docker/build-push-action actions, and add the version
numbers as trailing comments to maintain clarity about which versions are being
used.
- Around line 26-27: The workflow is missing an explicit setup step for Docker
Buildx before the docker/build-push-action@v6 step. Add a new step that uses
docker/setup-buildx-action before the "Build and push Docker image" step to
properly initialize Buildx and enable build caching features. This ensures the
documented setup is followed and allows you to leverage cache optimization in
subsequent build steps.
In `@docker-compose.yml`:
- Around line 21-35: The frontend service in the docker-compose.yml file
currently passes API_BASE_URL as both a build argument (in the build.args
section) and as a runtime environment variable. Since Next.js does not bake
private environment variables (those without the NEXT_PUBLIC_ prefix) into the
build, the build argument is redundant. Remove the API_BASE_URL build arg from
the build.args section under the frontend service, while keeping the environment
variable definition in the environment section, as this is where the value is
actually used at runtime.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 65353c26-42be-463b-adca-fe4464ef4b80
📒 Files selected for processing (9)
.github/workflows/docker-image.yml.gitignoreDOCKER.mdDockerfileREADME.mddocker-compose.ymldocker/.env.local.coc-api.exampledocker/.env.local.frontend.examplepackage.json
| context: . | ||
| file: ./Dockerfile | ||
| push: ${{ github.event_name == 'push' }} | ||
| tags: callofcode07/callofcode:latest |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the docker-image.yml workflow file to see the full context
cat -n .github/workflows/docker-image.ymlRepository: call-0f-code/call-of-code
Length of output: 1155
🏁 Script executed:
# Now examine docker-compose.yml to see what images it references
cat -n docker-compose.ymlRepository: call-0f-code/call-of-code
Length of output: 2145
🏁 Script executed:
# Search for references to the image names across the repository
rg "callofcode07/callofcode|callofcode07/coc-api|coc-frontend" --type yaml --type yml -nRepository: call-0f-code/call-of-code
Length of output: 191
🏁 Script executed:
# Search more broadly for image name references
rg "callofcode07|coc-api|coc-frontend" -n --no-heading | head -30Repository: call-0f-code/call-of-code
Length of output: 163
🏁 Script executed:
# Check the Dockerfile to see what's being built
cat -n Dockerfile | head -50Repository: call-0f-code/call-of-code
Length of output: 1481
🏁 Script executed:
# Search for any README or documentation that might explain the image naming
find . -name "README*" -o -name "*.md" | xargs grep -l "callofcode07\|docker" 2>/dev/null | head -5Repository: call-0f-code/call-of-code
Length of output: 187
🏁 Script executed:
# Check DOCKER.md for documentation about the image naming and architecture
cat -n DOCKER.mdRepository: call-0f-code/call-of-code
Length of output: 7972
🏁 Script executed:
# Also check README.md for relevant information
cat README.md | grep -A 20 -B 5 "docker\|image" -i | head -60Repository: call-0f-code/call-of-code
Length of output: 1655
Published image name doesn't match what the dev stack uses; align or document the separation.
The workflow publishes to callofcode07/callofcode:latest, but the dev stack in docker-compose.yml pulls callofcode07/coc-api:latest for the API and builds the frontend locally as coc-frontend:dev. The published callofcode07/callofcode image is unused in the local development workflow, making this an orphaned build artifact. Per DOCKER.md, the stack has no reference to this image.
Additionally, publishing only :latest leaves no immutable tag for rollbacks or debugging past deployments.
Consider either:
- Aligning the published image name with what dev stack consumes, or
- Adding a documentation comment explaining why the published image differs from local builds
🔧 Suggested tagging
- tags: callofcode07/callofcode:latest
+ tags: |
+ callofcode07/callofcode:latest
+ callofcode07/callofcode:${{ github.sha }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| tags: callofcode07/callofcode:latest | |
| tags: | | |
| callofcode07/callofcode:latest | |
| callofcode07/callofcode:${{ github.sha }} |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/docker-image.yml at line 32, In the docker-image.yml
workflow file, the tags property at line 32 currently specifies
`callofcode07/callofcode:latest`, which does not align with the image names
referenced in docker-compose.yml (callofcode07/coc-api:latest for the API
service). Either update the published image name in the tags property to match
what the dev stack expects (callofcode07/coc-api), or add a comment in the
workflow explaining the intentional separation between the published image and
local development images. Additionally, replace the single `:latest` tag with
multiple tags including both a version-based immutable tag (e.g., using git
commit SHA or version number) and the `:latest` tag to enable proper rollback
and debugging of past deployments.
| # Stage 3 – runner: lean production image | ||
| FROM node:20-alpine AS runner | ||
| WORKDIR /app | ||
|
|
||
| ENV NODE_ENV=production | ||
|
|
||
| # Next.js standalone output (enable in next.config if needed) | ||
| # COPY --from=builder /app/.next/standalone ./ | ||
| # COPY --from=builder /app/.next/static ./.next/static | ||
| # COPY --from=builder /app/public ./public | ||
|
|
||
| # Standard (non-standalone) output | ||
| COPY --from=builder /app/public ./public | ||
| COPY --from=builder /app/.next ./.next | ||
| COPY --from=builder /app/node_modules ./node_modules | ||
| COPY --from=builder /app/package.json ./package.json | ||
|
|
||
| EXPOSE 3001 | ||
|
|
||
| CMD ["npm", "run", "start"] |
There was a problem hiding this comment.
🩺 Stability & Availability | 🔴 Critical | ⚡ Quick win
Runtime environment variable API_BASE_URL is not available in the runner stage.
The builder stage sets API_BASE_URL as an ARG and ENV (lines 17–18), but build-time ARGs are not inherited by subsequent stages. The runner stage has no corresponding ENV directive to make API_BASE_URL available at runtime.
The upstream code (app/api/projects-with-members/route.ts and app/achievements/page.tsx) requires process.env.API_BASE_URL at runtime. When the runner image is executed standalone (outside Compose), the app will fail with "API_BASE_URL not set" errors (HTTP 500).
Recommendation: Either:
- Accept
API_BASE_URLas a runtime ENV var in the runner stage (users provide it viadocker run -e API_BASE_URL=...or in a.envfile). - Or document that the runner image requires API_BASE_URL to be passed at container startup.
🔧 Proposed fix: Accept API_BASE_URL at runtime
# Stage 3 – runner: lean production image
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
+ENV API_BASE_URL="" # Set at runtime via -e or .env
# Next.js standalone output (enable in next.config if needed)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile` around lines 22 - 41, The runner stage in the Dockerfile does not
declare the API_BASE_URL environment variable, which is needed at runtime by the
Next.js application code in app/api/projects-with-members/route.ts and
app/achievements/page.tsx. After the ENV NODE_ENV=production line in the runner
stage (FROM node:20-alpine AS runner), add an ENV directive to declare
API_BASE_URL as an environment variable. This allows users to provide the value
at runtime via docker run -e API_BASE_URL=... or similar runtime mechanisms,
ensuring the variable is available when the container starts.
…or Docker container
2 participants
Summary by CodeRabbit
Release Notes
Documentation
Chores