-
Notifications
You must be signed in to change notification settings - Fork 2.8k
execute-type param addition in GkeCodeExecutor #4111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Summary of ChangesHello @SHRUTI6991, I'm Gemini Code Assist1! 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 enhances the Highlights
🧠 New Feature in Public Preview: You can now enable Memory 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 AssistThe 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
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 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
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a new execution path in GkeCodeExecutor to use agentic-sandbox, controlled by a new executor_type parameter. The changes are logical and the addition of unit tests for the new branching logic is great. My feedback focuses on improving robustness, configurability, and code quality. Key suggestions include pinning the new git dependency for build stability, making the sandbox template name configurable, ensuring consistent logger usage, fixing a potential type error, and making the executor type selection logic more robust.
| kubeconfig_context: str | None = None | ||
|
|
||
| # Sandbox constants | ||
| python_sandbox_template: str = "python-sandbox-template" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we allow python_sandbox_template to be passed into init? If we ever want to support different template (e.g., a data-science specific image), we'll need to make this configurable.
Maybe i'm missing some context or forgetting something but yeah, why are we hardcoding the template name ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hardcoded it because, currently we only support python runtime. If we provide any runtime which doesn't support python. This code might fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed on allowing the user to override the value. Whatever template they use must be available in their cluster, so even with this value hard-coded it can fail if not properly set up.
That being said I'd recommend being able to override the value as part of the execute_code rather than the init method. That way the executor can be used with multiple different templates (assuming that each template is valid and available in the cluster).
vicentefb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The separation between the Job and Sandbox logic is clean. I have just a few comments.
| kubeconfig_context: str | None = None | ||
|
|
||
| # Sandbox constants | ||
| python_sandbox_template: str = "python-sandbox-template" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed on allowing the user to override the value. Whatever template they use must be available in their cluster, so even with this value hard-coded it can fail if not properly set up.
That being said I'd recommend being able to override the value as part of the execute_code rather than the init method. That way the executor can be used with multiple different templates (assuming that each template is valid and available in the cluster).
| class GkeCodeExecutor(BaseCodeExecutor): | ||
| """Executes Python code in a secure gVisor-sandboxed Pod on GKE. | ||
| This executor securely runs code by dynamically creating a Kubernetes Job for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you modify this comment block to indicate the difference between Job vs Sandbox? In particular that Sandbox will need other resources available in the cluster (agent-sandbox controller, sandbox-template, client router and gateway, etc.) in order for this code to properly work.
The comment here doesn't need to be extensive. A more detailed update should be added to the docs https://github.com/google/adk-docs/blob/main/docs/tools/google-cloud/gke-code-executor.md after this PR is merged.
Description:
Link to an existing issue (if applicable):
#3263
This PR updates the
GkeCodeExecutorto add a new param calledexecutor_typewhich takes eitherjob/sandbox. CurrentlyGkeCodeExecutorcan only execute python code, so the changes made also focusses on executing ONLY python code via sandbox client.Testing Plan
Unit Tests:
Addition of new Unit tests to verify forking of code between
sandboxvsjob.Please include a summary of passed
pytestresults.-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
======================== 9 passed, 2 warnings in 2.72s =========================
Finished running tests!
Manual End-to-End (E2E) Tests:
Integration test by running a simple AI Agent: https://google.github.io/adk-docs/tools/google-cloud/gke-code-executor/ to write and execute Python code. The sandbox was connected via local tunnel for testing.
Output:
Checklist
Additional context
Add any other context or screenshots about the feature request here.