[ponharu]

Why

wb deploy --containers-rollout=gradual|immediate validates every Wrangler container entry with a schema that requires image. A container that uses the Durable Object scheduling policy has no application-wide image; it names its images under images (for example images.app.dockerfile). Deploying such a configuration fails before anything is built:

ZodError: [{ "expected": "string", "code": "invalid_type", "path": ["containers", 1, "image"], ... }]

Requirements

• required: not recorded — ask the requester
• required: containers with an application-wide image keep reusing published images built from committed Git contexts (existing contract)
• chosen: wb passes Durable Object-managed containers to Wrangler unchanged, and Wrangler builds their images, because a named registry image must be a digest-pinned reference and the registry listing wb uses exposes tags only
• chosen: before deploying, wb rejects uncommitted or untracked files in the build context of each named Dockerfile image, so that these images, like the reused ones, contain committed sources only

Customer Summary

Projects can deploy Containers that use the Durable Object scheduling policy with wb deploy --containers-rollout=gradual or immediate.

Technical Summary

• packages/wb/src/utils/containerImages.ts
  • The container schema makes image optional and accepts images (named images with an optional dockerfile and build_context).
  • Only containers whose image points to a local Dockerfile go through image reuse, as before.
  • For each named image with a dockerfile, git status --porcelain --untracked-files=all over its build context must be empty; otherwise the deploy stops with the existing "Commit container build context changes before deploying" error.
• What to check hardest: the build context check resolves the Dockerfile path relative to the deployed configuration file. When a build step writes that file to another directory, it must rewrite the paths relative to the new location, as Wrangler expects.

Testing

• bun run verify
• bun test test/unit/containerImages.test.ts in packages/wb (26 tests). Two new tests:
  • A configuration with a default-policy container and a Durable Object-managed one deploys; the default image is replaced with a registry reference and the Durable Object entry reaches Wrangler unchanged. It fails when image is required again.
  • An untracked file in a named image's build context stops the deploy. It fails when the check is removed.

Notes

• The requester's instructions are not recorded in this PR, so the first Requirements line asks the requester to confirm them.

[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 enables the deployment of containers using the Durable Object scheduling policy by relaxing the requirement for an application-wide 'image' field in the configuration. It introduces a schema update to support named images and enforces strict build context validation to ensure that only committed sources are used for these deployments, aligning with the project's existing deployment safety standards.

Highlights

• Support for Durable Object-managed containers: Updated the container schema to make the 'image' field optional and added support for 'images' (named images), allowing containers using the Durable Object scheduling policy to be deployed.
• Build context validation: Implemented a check to ensure that named container images have no uncommitted or untracked files in their build context before deployment, maintaining consistency with existing image reuse contracts.
• Deployment workflow integration: Ensured that Durable Object-managed containers are passed to Wrangler unchanged, while standard containers continue to benefit from image reuse.

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.

---

Containers managed by the DO, No image field for them to show. We check the git status, To avoid any hiatus, And let the deployment flow.

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 adds support for Durable Object-managed containers by updating the container schema to allow optional image fields and introducing an images record for named images. It also adds validation to ensure that build contexts for these named images are committed in git before deployment. The review feedback suggests removing an explanatory comment that violates the repository's style guide on redundant comments, and optimizing the git assertion loop by running the checks in parallel using Promise.all.

[gemini-code-assist]

Since assertCommittedNamedImageSource performs I/O-bound git operations, running these assertions sequentially in a nested loop can be slow if there are multiple containers or images. We can run them in parallel using Promise.all to improve deployment performance.

  const assertions: Promise<void>[] = [];
  for (const container of containers) {
    for (const image of Object.values(container.images ?? {})) {
      if (image.dockerfile) {
        assertions.push(assertCommittedNamedImageSource(configDir, image.dockerfile, image.build_context, run));
      }
    }
  }
  await Promise.all(assertions);

[ponharu]

A configuration names one or two images in practice, so the check runs a handful of short git commands before a deploy that builds and uploads container images. Running them in parallel would not change the deploy time noticeably, and the sequential loop stops at the first dirty context with a single clear error. Keeping it sequential.