fix: prevent pnpm auto-install during Docker build#74
Conversation
|
Codex strikes again 😃 |
|
Builds passing again now 😃 The new OpenClaw release made installs more deterministic: The relevant bit is the generated shrinkwrap / locked dependency graph work. So I think the immediate failure got masked because upstream is less likely to resolve a surprise dependency during install now I think better to still merge this. Even with the upstream shrinkwrap changes, this keeps the Docker build tied to the dependencies installed by pnpm install --frozen-lockfile so no pnpm build taking a second pass at dependency verification/install later causing issues like this again |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis PR configures the ✨ 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 |
|
Thank you for the PR! 💜 |
Summary
Fixes the scheduled Docker image build for OpenClaw releases that use pnpm 11 by preventing
pnpm buildfrom auto-running a second dependency install after the Docker metadata patch.The Dockerfile still installs dependencies from the upstream release lockfile with
pnpm install --frozen-lockfile; this only disables pnpm's pre-script dependency freshness auto-install for the later build commands.Root Cause
This is similar to #63, but one layer deeper.
PR #69 fixed the explicit post-patch install by moving dependency installation before the Dockerfile relaxes bundled extension
openclawworkspace/peer references.The new failure happens because OpenClaw
v2026.5.20usespnpm@11.1.0. pnpm 11 defaultsverifyDepsBeforeRuntoinstall, so whenpnpm buildruns after the metadata patch, pnpm seesnode_modulesas stale and implicitly runs anotherpnpm install.That implicit install re-enters dependency resolution and hits OpenClaw's
minimumReleaseAge: 2880guard:Because the base image build fails, the versioned image and final
latestmanifest are never pushed, leavinglateston the previous successful OpenClaw image.Why This Fix
pnpm install --frozen-lockfile.minimumReleaseAgeprotection during actual dependency installation.pnpm build/pnpm ui:build.Verification
I reproduced the failing path against
v2026.5.20from the failed scheduled build.With this change, the Docker build passed the previous failure point:
pnpm buildstarted the OpenClaw build directly instead of auto-runningpnpm installand failing on@google/genai.My local Docker build later exited during upstream
tsdownwith SIGTERM, which appears unrelated to theminimumReleaseAgefailure and likely due to local builder resources.git diff --checkpasses.Fixes #73.