[cv]

Summary

Hardens sandbox image builds against npm registry/network resets by increasing npm fetch retry and timeout settings. This targets the npm ci steps used to build and install the NemoClaw plugin inside the OpenClaw sandbox image.

Changes

• Adds npm fetch retry and timeout configuration to the Docker builder stage before npm ci && npm run build.
• Applies the same npm fetch retry and timeout configuration before the runtime npm ci --omit=dev step.

Type of Change

• Code change (feature, bug fix, or refactor)
• Code change with doc updates
• Doc only (prose changes, no code sample modifications)
• Doc only (includes code sample changes)

Verification

• npx prek run --all-files passes
• npm test passes
• Tests added or updated for new or changed behavior
• No secrets, API keys, or credentials committed
• Docs updated for user-facing behavior changes
• make docs builds without warnings (doc changes only)
• Doc pages follow the style guide (doc changes only)
• New doc pages include SPDX header and frontmatter (new pages only)

---

Signed-off-by: Carlos Villela cvillela@nvidia.com

Summary by CodeRabbit

• Chores
  • Improved build process reliability by enhancing dependency installation configuration with retry and timeout settings.

[coderabbitai]

📝 Walkthrough

Walkthrough

The Dockerfile now configures npm registry-fetch retry and timeout settings to improve build resilience. Both the builder stage (TypeScript plugin build) and runtime stage receive npm environment variables controlling retry counts, min/max fetch timeouts, and overall fetch timeout behavior before dependency installation.

Changes

Docker npm network resilience configuration

Layer / File(s)	Summary
npm registry retry and timeout configuration Dockerfile	Builder and runtime stages both get npm ENV blocks configuring registry fetch retries and timeouts: retry counts, fetch timeout min/max thresholds, and overall fetch timeout. Builder stage expands existing ENV block; runtime stage adds a new block before npm ci --omit=dev.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A rabbit hops through Docker's layers neat,
With npm retries, timeouts replete,
Building and running with grace so fine,
Network resilience by design! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: adding npm fetch retry logic to Docker builds during sandbox image creation.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/docker-npm-retries

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

Dockerfile (1)

16-27: Run the Docker E2E workflow before merge.

Given this is a Docker-layer behavior hardening change, please run the recommended cloud-e2e,sandbox-survival-e2e,hermes-e2e,rebuild-openclaw-e2e jobs to validate real build/runtime behavior.

As per coding guidelines, Dockerfile changes are “only testable with a real container build.”

Also applies to: 69-76

🤖 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 16 - 27, This change modifies Docker layer behavior
around the build stage (ENV settings, COPY of nemoclaw package.json/tsconfig and
src, WORKDIR /opt/nemoclaw, and the RUN npm ci && npm run build step) and must
be validated by running the real container builds; run the recommended E2E jobs
(cloud-e2e, sandbox-survival-e2e, hermes-e2e, rebuild-openclaw-e2e) to build and
run the container image, verify the layers and runtime behavior, and report any
build/runtime failures or differences before merging.

🤖 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.

Nitpick comments:
In `@Dockerfile`:
- Around line 16-27: This change modifies Docker layer behavior around the build
stage (ENV settings, COPY of nemoclaw package.json/tsconfig and src, WORKDIR
/opt/nemoclaw, and the RUN npm ci && npm run build step) and must be validated
by running the real container builds; run the recommended E2E jobs (cloud-e2e,
sandbox-survival-e2e, hermes-e2e, rebuild-openclaw-e2e) to build and run the
container image, verify the layers and runtime behavior, and report any
build/runtime failures or differences before merging.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 1729b2dd-ccec-4906-ae60-d2f7e8465149

📥 Commits

Reviewing files that changed from the base of the PR and between 68dc45d and a8485cc.

📒 Files selected for processing (1)

• Dockerfile

[github-actions]

E2E Advisor Recommendation

Required E2E: build-sandbox-images, test-e2e-sandbox
Optional E2E: test-e2e-gateway-isolation, test-non-root-sandbox-smoke, runtime-overrides-e2e, rebuild-openclaw-e2e

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• build-sandbox-images (low): Builds the production Dockerfile and then layers the sandbox test image on top; this is the most direct required validation for the changed npm install/build stages.
• test-e2e-sandbox (low): Runs the sandbox image smoke/E2E suite inside the image, validating OpenClaw CLI presence, plugin install/build artifacts, blueprint validity, and blueprint runner behavior after the Dockerfile packaging change.

Optional E2E

• test-e2e-gateway-isolation (low): Useful adjacent confidence because the production Dockerfile defines the runtime security boundary and gateway/sandbox user layout, though the specific diff only changes npm fetch retry configuration.
• test-non-root-sandbox-smoke (low): Optional smoke for production-image entrypoint behavior under no-new-privileges; helpful for Dockerfile/runtime image changes but not directly targeted by the npm retry diff.
• runtime-overrides-e2e (medium): Builds the production Dockerfile and runs short-lived containers through the entrypoint/config patch path, providing broader runtime-image confidence if maintainers want an additional workflow-dispatched check.
• rebuild-openclaw-e2e (high): Optional higher-cost full lifecycle check for rebuild/upgrade paths that consume the current OpenClaw Dockerfile image; useful if there is concern about stale-base upgrade or npm install behavior during real sandbox rebuilds.

New E2E recommendations

• sandbox image build configuration (low): Existing image E2Es validate that the Dockerfile builds and runs, but they do not explicitly assert the intended npm retry/fetch timeout configuration in the final image or builder logs.
  • Suggested test: Add a lightweight assertion to the sandbox image E2E that npm config get fetch-retries, fetch-retry-mintimeout, fetch-retry-maxtimeout, and fetch-timeout match the Dockerfile defaults in the built production image.

[cjagwani]

Solid resilience tweak — minimum diff, both npm ci stages covered (builder + runtime, runtime ENV correctly precedes the global npm install -g RUNs at :92/:101), no new security surface. CI green across all 27 checks.

Three small nits, none blocking:

1. Dockerfile:18-22 and :68-75 — worth a one-line # Why: comment above the ENV block explaining the rationale (transient registry resets on shared CI with flaky egress). The variable names don't telegraph why these specific values (5 retries, 20s/120s/300s).
2. Follow-up (separate ticket) — nothing currently asserts these settings survive in the built image. A 4-line E2E check (npm config get fetch-retries etc.) would prevent silent regression if someone trims the block later. Out of scope here.
3. Optional — no Closes #N in the body. If this was prompted by a specific failing CI run, link it; otherwise a "no linked issue — proactive hardening" line helps the audit trail.

Happy to approve as-is.