[buildpulser]

On lean EC2 hosts (BP_SUBSTRATE=ec2), the buildkit root stays on the host and the BuildPulse agent commits it after the job. The post step still tried the NVMe copy, found no /home/runner/buildkit-root, and ended every docker-builder build with a NVMe cache commit skipped warning plus a CacheCommitErrors metric.

Now, after the prune, it logs one info line and exits. Nothing changes off lean.

Dev validation: EcoStackTech/docker-builder-e2e run 39931465026 (buildpulse-node-multistage pinned to 5026864) passed. The log shows lean host: the BuildPulse agent commits the layer cache after the job and no warning. Unit tests: 20/20 pass. The dist/ rebuild reproduces byte-for-byte from main before the change.

After merge: tag v2.2.2 and move v2.

🤖 Generated with Claude Code

[buildpulse-v2]

Agent code review

Walkthrough

This PR adds an early-exit guard in the post-step script (src/post.js + rebuilt dist/post.js) that detects lean EC2 hosts via BP_SUBSTRATE === 'ec2' and skips the NVMe copy and S3 cache-commit tiers entirely. On those hosts the BuildPulse agent handles cache commits after the job, so executing those tiers would fail with a warning and an error metric. Two files changed: the source (src/post.js) and its bundled output (dist/post.js).

Findings

• Suggestion: pruneCache() executes before the BP_SUBSTRATE guard, so docker buildx prune is still attempted on lean EC2 hosts (src/post.js:413). The prune is fail-safe (errors produce at most a non-fatal core.warning), so this cannot break a build — but it is worth confirming this is intentional rather than a missed hoist of the guard.

Verdict

The change is correct and purposeful. The early-exit path is a clean process.exit(0), the environment variable check is a simple string comparison with no injection surface, and no tests are weakened. The only non-blocking note is that pruneCache() still runs before the guard; if that is intentional (keeping the builder healthy on lean hosts) the code is exactly right as-is.

Confidence

HIGH — both changed files were fully read; the logic is compact and unambiguous.

💡 Tips for working with the BuildPulse reviewer

• Re-review on demand — comment @buildpulse review on the PR (/buildpulse review also works). The fresh review bills the requester's seat.
• Teach it by replying to a finding — reply to any inline comment: "we never do X here" becomes a standing rule for this repository (acknowledged in-thread, not raised again); "not in this PR" mutes the topic for this PR only. Replies are free. Org admins can view or remove learned rules on the AI Features page.
• Every push is re-reviewed automatically — smaller PRs get a fresh full review, larger ones get a delta review of what changed since the last look; an "Update branch" merge with an unchanged diff carries the previous verdict forward without a new billed review.
• Draft PRs are skipped until marked ready for review (repositories can opt in to draft reviews on the AI Features page).