Infra: Ensure sandbox image is built with Release process
This task is to migrate the hosting of our public sandbox Docker images from the private Google Artifact Registry to Docker Hub.
The Problem
Currently, our sandbox images are intended for public consumption but are hosted in a private Google Artifact Registry (us-west1-docker.pkg.dev/gemini-code-dev/...). This is not an ideal public distribution point because:
- Discoverability: Docker Hub is the default and most widely used container registry. Hosting our images there makes them easier for users to find and trust.
- Accessibility: While Artifact Registry can be configured for public access, it's not the standard workflow for most Docker users and can add unnecessary friction.
- Community Standard: Using Docker Hub aligns with open-source best practices and community expectations for public Docker images.
The Goal
To improve accessibility and align with community standards, we will publish our official sandbox images to a public repository on Docker Hub.
This involves:
-
Creating a Docker Hub Repository: Create an official public repository for the sandbox image under the
@googleorganization on Docker Hub. This is a multi-step process that requires coordination. Please ping @mattkorwel for information on the internal process for requesting a new repository under this organization. - Updating the Release Pipeline: Modify our release workflow to authenticate to Docker Hub (using a token stored as a GitHub secret) and push the final image to the new repository.
- Updating Documentation: Ensure any documentation or user-facing materials are updated to reference the new Docker Hub image path.
This change will make our sandbox environment more accessible and discoverable for our users and the wider open-source community.
Found possible duplicate issues:
- #3689: (0.9007900953292847)
- #3684: (0.9001484513282776)
Instead of Dockerhub, we've decided to go with GHCR, but all the same guidance still applies.
I added a sandbox job, here's what's outstanding:
- [~] Move it to Dockerhub (In progress)
- [ ] Hook it up to the release pipeline (easy enough).
Need dockerhub info @mattKorwel
Two repos:
- gemini-cli
- gemini-cli-sandbox
Two secrets:
- DOCKERHUB_USER (containing username)
- DOCKERHUB_TOKEN (containing PAT w/ R+W that was issued by {DOCKERHUB_USER})
Blocked on security review @ https://b.corp.google.com/issues/448140256
TDD @ https://docs.google.com/document/d/1LWwA72WK10So8Sg7ksYVc99FZCogd9H3k8xEnM6ua5E/edit?resourcekey=0-HlqQiAHQOzTFHJoXfk0A9w&tab=t.0
Secops Threat Analysis @ https://docs.google.com/document/d/1jUvyjjmSZb8NxWjDYxD42GBXMWlA3ua-enTeCk8yEJ4/edit?tab=t.0#heading=h.7oizlekf3gz6
Current Status: EIP (Joel F) is working on a process that will enable us to use WIF via an approved means. The actual assertion condition will be terraform managed and be managed by EIP. We will have a terraform configuration file that "fills in the blanks" (e..g repo name, org id, etc, etc). This will enable us to use WIF tokens.
There was a now-stale, but draft PR on this @ https://github.com/google-gemini/gemini-cli/pull/9941/files (This would need to be updated to use gCloud + docker gcloud login). I will try to update my prototype to get this a bit closer. I had something working with WIF and then discarded it when we had changed directions.
Once we have WIF tokens, we would be able to push to Artifact Registry via docker.
Hello! As part of our effort to keep our backlog manageable and focus on the most active issues, we are tidying up older reports.
It looks like this issue hasn't been active for a while, so we are closing it for now. However, if you are still experiencing this bug on the latest stable build, please feel free to comment on this issue or create a new one with updated details.
Thank you for your contribution!
Found possible duplicate issues:
- #3689
If you believe this is not a duplicate, please remove the status/possible-duplicate label.