[ponharu]

Why

Cloudflare container images rebuilt on separate CI runners can have different digests even when their committed build context is unchanged. Publishing those rebuilds can trigger unnecessary container replacements.

Requirements

required: not recorded — ask the requester

Customer Summary

Adds the opt-in wb deploy --reuse-container-images option to reuse a published container image when its committed build inputs are unchanged.

Technical Summary

• Derive a registry tag from the effective Worker name, committed Git context, Dockerfile path, build variables, and target platform.
• Build missing images from a Git archive and reject uncommitted tracked context changes.
• Substitute account-relative registry image references before Wrangler's dry run, preserving config-relative paths and migration ordering.
• Share explicit config selection and sanitized deployment environments across Wrangler commands; let Wrangler resolve account and registry hosts.
• Load single-platform Docker images before publishing, and clean temporary contexts/configs on success, failure, and handled shutdown signals.
• Document the supported build-context constraints in the wb README and repository rules.

Testing

• bun run verify passed.
• bun wb test test/unit/containerImages.test.ts (from packages/wb): 21 cases passed with 90 assertions, covering cross-checkout reuse, target isolation, changed inputs, container identifiers/build arguments, registry/account selection, profile environment isolation, root/workspace contexts, vinext paths, dirty contexts, and cancellation/failure cleanup.
• Full local verification encountered existing process-lifecycle test timeouts outside the changed code; a focused rerun of the failing case passed.
• A real Docker scratch build produced an inspectable linux/amd64 image with --load --provenance=false; its temporary image was removed.
• A real Wrangler dry run accepted account-relative image references without invoking Docker.
• All four current-head PR checks passed.
• No live deployment was performed.

Notes

The Requirements section uses the missing-request fallback because no public implementation specification is linked.
Build contexts are exported from Git; untracked files are not available to image builds. Changes to tracked context files can cause a rebuild even when Docker would ignore them.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!