-
Notifications
You must be signed in to change notification settings - Fork 3.4k
feat: Adding Docker CMD in all Dockerfiles #7339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughDefault startup commands were added to the Dockerfiles for the admin, live, server (API), space, and web applications. Each Dockerfile now includes a CMD instruction to specify which server script or entrypoint should run when the container starts. No changes to application code or exported entities were made. Changes
Suggested reviewers
Poem
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/server/Dockerfile.api (1)
52-52: Ensure entrypoint script forwards signals withexec
Good to see a dedicated CMD. Confirm thatbin/docker-entrypoint-api.shends withexec "$@"(or an equivalent) so SIGTERM/SIGINT reach the Python/uvicorn process; otherwise Kubernetes & Docker stop signals will be swallowed.apps/web/Dockerfile.web (1)
109-111: Path consistency across workspaces
Here we runnode apps/web/server.js, whereas the live image usesnode live/server.js. The difference is intentional (due to the pruning layout), but the inconsistency is easy to trip over later. Consider normalising to eitherapps/<name>/…everywhere or adding a brief comment explaining the rationale.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
apps/admin/Dockerfile.admin(1 hunks)apps/live/Dockerfile.live(1 hunks)apps/server/Dockerfile.api(1 hunks)apps/space/Dockerfile.space(1 hunks)apps/web/Dockerfile.web(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Analyze (javascript)
- GitHub Check: Analyze (python)
🔇 Additional comments (3)
apps/live/Dockerfile.live (1)
54-56: Verify port & path alignment with runtime server
EXPOSE 3000+node live/server.jspresumes the compiled live service is actually listening on port 3000 and that the server entry lives at/app/live/server.jsin the final image. Please double-check these two assumptions; a mismatch will result in the container starting but failing health checks.apps/admin/Dockerfile.admin (1)
92-94: LGTM – explicit startup command added
Defining the default CMD removes the need fordocker run … node …overrides. No issues spotted.apps/space/Dockerfile.space (1)
92-94: LGTM – container now self-starts
The addedCMDcorrectly targets the Next.js standalone output; looks good.
* fix: adding cmd to dockerfiles * fix: adding cmd to live docker file
Type of Change
Summary by CodeRabbit