Fix Railway Docker builds on Node 26#79
Conversation
|
WalkthroughBoth the Medusa and storefront Dockerfiles' base stages are updated to install, enable, and activate Corepack with yarn@4.9.1. Additionally, the Medusa runner stage's startup command now runs ChangesDockerfile Toolchain and Startup Updates
Estimated code review effort: 1 (Trivial) | ~5 minutes Related PRs: None identified. Suggested labels: docker, infrastructure Suggested reviewers: None identified. 🐰 Corepack awakens, yarn pinned tight, 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/medusa/Dockerfile (1)
4-4: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winPin Corepack to a fixed version.
npm install -g corepackfetches whatever is latest from npm during each build, so this image can drift even thoughyarn@4.9.1is fixed. Use an explicit Corepack version instead, for examplecorepack@0.35.0.🤖 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 `@apps/medusa/Dockerfile` at line 4, The Dockerfile setup is installing Corepack without a fixed version, which makes builds drift over time. Update the RUN step in the Dockerfile to install an explicit Corepack version instead of relying on the latest from npm, while keeping the existing corepack enable and corepack prepare yarn@4.9.1 --activate flow intact.
🤖 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 `@apps/medusa/Dockerfile`:
- Line 45: Running migrations in the container CMD causes every startup to
execute `yarn migrate:prod`, which can race across scaled or restarted
instances. Update the `CMD` in the Dockerfile so the app only starts `yarn
start:prod`, and move `migrate:prod` to a separate one-off deployment/release
step outside the steady-state container startup path.
---
Nitpick comments:
In `@apps/medusa/Dockerfile`:
- Line 4: The Dockerfile setup is installing Corepack without a fixed version,
which makes builds drift over time. Update the RUN step in the Dockerfile to
install an explicit Corepack version instead of relying on the latest from npm,
while keeping the existing corepack enable and corepack prepare yarn@4.9.1
--activate flow intact.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 094b9bf0-4bd1-40e1-82dd-40c37367e2fc
📒 Files selected for processing (2)
apps/medusa/Dockerfileapps/storefront/Dockerfile
| ENV PORT=80 | ||
|
|
||
| CMD ["yarn", "start:prod"] | ||
| CMD ["sh", "-c", "yarn migrate:prod && yarn start:prod"] |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Running migrate:prod on every container start risks concurrent migrations on scaled/restarted instances.
If Railway ever runs more than one replica, or restarts the container concurrently (deploy + health-check restart overlap), multiple instances will race to run medusa db:migrate at the same time, which can produce partial/locked schema changes. Consider running migrations as a separate one-off release step (e.g., Railway's pre-deploy/release command) rather than embedding it in the container's steady-state CMD.
🤖 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 `@apps/medusa/Dockerfile` at line 45, Running migrations in the container CMD
causes every startup to execute `yarn migrate:prod`, which can race across
scaled or restarted instances. Update the `CMD` in the Dockerfile so the app
only starts `yarn start:prod`, and move `migrate:prod` to a separate one-off
deployment/release step outside the steady-state container startup path.
1 participant
Summary
Verification
Notes
Railway storefront build failed at
RUN yarn installwith/bin/sh: yarn: not foundafter moving tonode:26-alpine. The Node 26 Alpine image also lackscorepack, so the Dockerfiles install Corepack with npm before activating the repo-pinned Yarn version.Summary by CodeRabbit