fix(cli): enable multi-arch docker builds for sandbox

[ru-aish]

Summary

Fixes the exec format error and failed to map segment from shared object crashes that occur when running the sandbox on ARM64 hosts (like the Raspberry Pi 5). This enables multi-architecture Docker builds in the sandbox release pipeline.

Details

The GitHub Actions workflow building the sandbox image currently defaults to only linux/amd64. When an arm64 host pulls the image, Docker attempts to run it using QEMU emulation, resulting in low-level memory mapping failures (specifically when executing groupadd).

This change passes --platform linux/amd64,linux/arm64 and --push to the buildx executor within the Actions pipeline. Docker automatically publishes the multi-arch manifest.

Related Issues

Fixes #15778

How to Validate

1. Trigger the Github Actions Release Sandbox workflow (or wait for the nightly).
2. Note the build process correctly building both architecture variants using docker buildx.
3. Test locally on an ARM64 host (e.g., Raspberry Pi 5):
   • Re-run gemini -s.
   • The native image will be pulled, and the sandbox will start successfully without emulation crashing.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
  • Windows
  • Linux

[gemini-code-assist]

Summary of Changes

Hello @ru-aish, 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 significantly enhances the compatibility of the sandbox environment by enabling multi-architecture Docker builds. It directly addresses runtime errors encountered on ARM64 hosts, ensuring that users on these platforms can seamlessly run the sandbox without issues related to emulation or incorrect architecture. The change streamlines the build and publishing process within the CI/CD pipeline, making the sandbox more robust and accessible across diverse hardware.

Highlights

• Multi-architecture Docker Builds: Enabled multi-architecture Docker builds for the sandbox image, specifically targeting linux/amd64 and linux/arm64 platforms.
• ARM64 Host Compatibility Fix: Resolved exec format error and failed to map segment from shared object issues that occurred when running the sandbox on ARM64 hosts (e.g., Raspberry Pi 5) by providing native ARM64 images.
• Streamlined Image Publishing: Integrated the image publishing process directly into the npm run build:sandbox command by passing the --push flag, removing a separate docker push step in the GitHub Actions workflow.

Changelog

• .github/actions/push-sandbox/action.yml
  • Added a new environment variable BUILD_SANDBOX_FLAGS to pass multi-platform and push options to the sandbox build command.
  • Removed the dedicated 'publish' step, as the image pushing is now handled by the build command itself when the --push flag is active.

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 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 counter productive. 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, 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 correctly addresses the issue of single-architecture Docker builds for the sandbox by enabling multi-arch builds for linux/amd64 and linux/arm64. The approach of using docker buildx with the --platform and --push flags is the standard way to achieve this. The change to the GitHub Actions workflow is concise and effective. I have one suggestion to improve the readability and robustness of the conditional expression used to add the --push flag.

[ru-aish]

/gemini review

[gemini-code-assist]

Code Review

The pull request correctly implements multi-architecture Docker builds for the sandbox, which is a significant improvement for ARM64 compatibility. However, there are two issues that need to be addressed: an invalid expression syntax in the GitHub Actions workflow and the accidental inclusion of a temporary file (pr_body.txt).

[ru-aish]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly enables multi-architecture Docker builds for the sandbox image by updating the GitHub Actions workflow. The change properly uses docker buildx with the --platform flag to build for both linux/amd64 and linux/arm64. The logic to conditionally push the image using the --push flag based on the dry-run input is also sound, and the removal of the now-redundant docker push step is appropriate. The implementation looks solid and should resolve the reported issues on ARM64 hosts.

[ru-aish]

@gemini-cli-maintainers pls review

[scidomino]

Thanks for this PR! However, there is an issue with how docker buildx build behaves that will cause the GitHub Actions workflow to fail during a dry run (dry-run: true).

When you use docker buildx build with multiple platforms (like --platform linux/amd64,linux/arm64), Docker cannot load the resulting multi-architecture image into the local Docker daemon.

If dry-run is true, the --push flag is omitted. The build will succeed, but the image will not be pushed to the registry and cannot be loaded locally. As a result, the immediate next step in the action (verify), which attempts to run a docker run command using the newly built image, will fail with an "image not found" error because the image exists neither locally nor remotely.

To fix this, we need to handle the dry-run case differently. For example, during a dry-run, we should build only for a single architecture (e.g., linux/amd64) and use the --load flag so the image is available locally for the verify step. For non-dry runs, we can use the multi-platform flags with --push.

Could you please update the PR to handle the dry-run scenario? Something like this should work:

      env:
        GEMINI_SANDBOX_IMAGE_TAG: '${{ steps.image_tag.outputs.FINAL_TAG }}'
        GEMINI_SANDBOX: 'docker'
        BUILD_SANDBOX_FLAGS: "${{ inputs.dry-run != 'true' && '--platform linux/amd64,linux/arm64 --push' || '--platform linux/amd64 --load' }}"

[ru-aish]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly enables multi-architecture Docker builds for the sandbox environment by updating the GitHub Actions workflow. The change correctly uses docker buildx with the --platform and --push flags for multi-arch builds, and removes the now-redundant docker push step. My feedback includes a suggestion to improve the readability of the conditional logic in the workflow file for better long-term maintainability.

[ru-aish]

@scidomino I have change as suggested. gemini review is Hallucinating GitHub Actions expressions do NOT support an if() function.

[scidomino]

Also, rebase to main and resolve the merge conflicts.

[ru-aish]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly enables multi-architecture Docker builds for the sandbox environment. The changes, which include adding QEMU setup and updating the Docker build flags to build and push for both amd64 and arm64 architectures, are logical and well-implemented. The related workflow steps for verification and publishing are also correctly adjusted. I have one suggestion to improve the clarity of the conditional logic in the GitHub Actions workflow.

[scidomino]

The more I think about it the less I like the idea of skipping verification when not doing a dry run.

Can we change it to do this instead:

Keep build and verify exactly as it is now (where it only builds amd64), but in the publish step, build both and publish them.

[ru-aish]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the sandbox release pipeline to support multi-architecture Docker builds for linux/amd64 and linux/arm64 using setup-qemu-action and docker buildx. However, a critical command injection vulnerability was identified due to an unquoted environment variable in a shell command. Additionally, the Docker image name in the publish step is incorrectly configured to push to Docker Hub instead of the authenticated GitHub Container Registry, which will cause the workflow to fail.

[ru-aish]

/gemini review

[gemini-code-assist]

Code Review

The pull request successfully enables multi-architecture Docker builds for the sandbox, addressing the exec format error on ARM64 hosts. The addition of QEMU setup and the use of buildx with multi-platform flags are key to this fix. However, the current implementation introduces a redundancy where the amd64 Docker image is built twice within the workflow, once for local loading and again as part of the multi-architecture push, which could be optimized.