[ponharu]

Why

For containers that name their images under images (Durable Object scheduling policy), Wrangler builds the image itself. wb deploy pointed Wrangler at the working tree, and only checked git status for the build context, which does not report git-ignored files. Ignored local files (for example .env) inside the build context could therefore be sent to the Docker build and end up in the deployed image. Single-image containers (image) already build from a git archive extraction and were not affected.

Requirements

• required: not recorded — ask the requester
• required: a single-image container keeps building and reusing images from its committed build context as before (existing contract)
• required: a deploy with uncommitted tracked edits in a container build context fails with "Commit container build context changes before deploying" (existing contract)
• chosen: named images are built by Wrangler from an extracted copy of the committed build context, because this reuses the same git archive path as single-image containers and makes untracked and ignored files unreachable instead of trying to detect them

Customer Summary

wb deploy --containers-rollout=gradual|immediate now deploys Durable Object-managed container images built only from committed files. Untracked or git-ignored files in the build context no longer block the deploy and are never included in the image.

Technical Summary

• packages/wb/src/utils/containerImages.ts: each images entry with a dockerfile is extracted with git archive into the temporary directory, and its dockerfile and build_context in the temporary Wrangler config are rewritten to that copy. The source wrangler.json is not modified.
• The committed-tree resolution (tracked-diff check and Dockerfile-in-context check) and extraction are shared by single-image and named-image containers.
• The temporary config is now also written when only named images exist, so the deployment always reads the rewritten paths.

Testing

• bun wb test packages/wb/test/unit/containerImages.test.ts (26 pass): a named image deploy with an ignored .env and an untracked file in its context hands Wrangler a context containing only the committed Dockerfile, leaves wrangler.json unchanged, and a tracked edit to that context is rejected.
• bun run verify
• Not exercised here: a real Wrangler build from the rewritten absolute paths; it will be checked with a real deploy after release.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request improves the reliability and security of the deployment process for Durable Object-managed container images. By switching to an extraction-based build approach using git archive, the system ensures that the build context is strictly limited to committed sources. This change eliminates the risk of including local environment variables or untracked files in the final image, ensuring consistent builds across different environments.

Highlights

• Build Isolation: Implemented git archive extraction for Durable Object-managed images to ensure that only committed files are included in the build context.
• Security and Reproducibility: Prevented local, untracked, or ignored files (such as .env) from leaking into deployed images by using a temporary extracted build context.
• Testing: Updated unit tests to verify that ignored files are correctly excluded and that tracked edits to the build context are properly validated.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

---

The code was loose, the files were stray, Local secrets slipped away. Now git archive locks the gate, Committed source defines our fate.

Footnotes

1. Review the Generative AI Prohibited Use Policy, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors container image handling to ensure that Wrangler builds Durable Object-managed images exclusively from committed sources. This is achieved by extracting the committed git tree of the build context into a temporary directory before deployment. A review comment points out a violation of the style guide, suggesting the removal of redundant path-separator normalization since the codebase only targets macOS and Linux.