-
Notifications
You must be signed in to change notification settings - Fork 1
Updates #331
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
Updates #331
Conversation
📝 WalkthroughWalkthroughDocumentation updates across CLI and Services: added SSH-to-sandbox and API key CLI examples; replaced deployment custom-domains workflow with resource configuration; expanded sandbox docs (files, ports, runtimes, env, snapshots) and SDK execution surface; removed legacy object-storage docs; added DB create options. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant SDK
participant SandboxService
participant Runtime
Client->>SDK: sandbox.execute(sandboxId, options)
SDK->>SandboxService: POST /sandboxes/{id}/execute
SandboxService->>Runtime: start execution (container/process)
Runtime-->>SandboxService: execution started (executionId)
SandboxService-->>SDK: 202 Accepted + execution metadata (executionId, stream URLs)
SDK-->>Client: return Execution object (executionId, status, exitCode?, stdoutStreamUrl, stderrStreamUrl, durationMs)
Runtime->>SandboxService: send execution status updates/completion
SandboxService->>SDK: update/status endpoints or stream URLs reflect output
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 1✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (3)
🔇 Additional comments (16)
✏️ Tip: You can disable this entire section by setting Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
jhaynie
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.
LGTM but left a few comments
| ```json | ||
| { | ||
| "deployment": { | ||
| "resources": { |
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.
do we want to put "domains": [] to show that you can configure domains? i believe that is now the default when i create a new project
| | `sandbox execution` | View execution history | | ||
| | `sandbox runtime list` | List available runtimes | | ||
| | `sandbox env <id>` | Manage environment variables | | ||
|
|
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.
we have build and generate commands that will come out in tonights release
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.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@content/Reference/CLI/deployment.mdx`:
- Around line 316-329: The JSON example's "memory" value ("512Mi" in the
deployment example object) conflicts with the documented Defaults line (`memory:
"500Mi"`); update either the example's "memory" field to "500Mi" to match the
Defaults, or change the Defaults text to "512Mi" if that is the true default, or
add a clarifying note that the example uses a custom memory value; adjust the
"memory" value or the Defaults text accordingly and ensure the keys `"memory"`
and the Defaults sentence remain consistent.
In `@content/Reference/CLI/sandbox.mdx`:
- Line 56: Update the runtime example value in the CLI sandbox documentation:
replace the unrealistic `python:3.14` value shown alongside the `--runtime
<runtime>` option with a currently released Python version such as `python:3.12`
or `python:3.13` so the example reflects a real, supported runtime.
🧹 Nitpick comments (3)
content/Reference/CLI/sandbox.mdx (2)
189-192: Clarify the--networkrequirement wording.Line 191 states the
--networkflag is required "for outbound access," but in the context of port mapping (exposing a service to the internet), users may expect it to be about inbound access. Consider clarifying that--networkenables network connectivity (both inbound via the exposed port and outbound for the sandbox to reach external services).Suggested clarification
Port constraints: - Must be between 1024 and 65535 (no privileged ports) -- Requires `--network` flag for outbound access +- Requires `--network` flag (enables network connectivity) - Each sandbox can expose one port
654-680: Consider documenting how to view existing environment variables.The section documents setting and deleting environment variables, but it's unclear how users can list/view the current environment variables of a sandbox. If running the command without
KEY=VALUEarguments shows current variables, consider adding an example:Suggested addition
```bash +# List current environment variables +agentuity cloud sandbox env sbx_abc123 + # Set an environment variable agentuity cloud sandbox env sbx_abc123 MY_VAR=valueIf listing environment variables is supported, please add documentation for it. If not, consider clarifying that this command is only for modifying variables.
content/Services/Sandbox/snapshots.mdx (1)
217-228: Consider adding--runtimeflag for clarity.In the Python environment example (line 218), the sandbox create command uses
--networkbut omits--runtime. Earlier examples (line 98) include--runtime bun:1. Consider specifying a runtime (e.g.,--runtime base:latest) for consistency and to clarify which base environment is being used.📝 Suggested improvement
# Python with common packages -agentuity cloud sandbox create --network +agentuity cloud sandbox create --runtime base:latest --network
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
content/Reference/CLI/deployment.mdxcontent/Reference/CLI/sandbox.mdxcontent/Reference/CLI/storage.mdxcontent/Services/Sandbox/index.mdxcontent/Services/Sandbox/sdk-usage.mdxcontent/Services/Sandbox/snapshots.mdxcontent/index.mdx
🔇 Additional comments (27)
content/Reference/CLI/storage.mdx (1)
249-258: LGTM! Clear documentation for database creation options.The added example demonstrating
--descriptionusage and the options table provide helpful documentation for users. The table formatting is correct, and the documentation integrates well with the existing structure.One minor observation: other create commands in this file (e.g.,
cloud storage createat line 108) don't have options tables. Consider adding similar tables for consistency across storage types in a follow-up if those commands also support additional options.content/Reference/CLI/deployment.mdx (1)
324-324: Good addition of the emptydomainsarray.This addresses the feedback about showing users that domains can be configured, while making it clear the default is an empty array.
content/Reference/CLI/sandbox.mdx (7)
23-35: LGTM!The Quick Reference table additions are well-organized and consistent with the detailed documentation sections below. The new commands (files, mkdir, rmdir, rm, download, upload, snapshot build/generate, runtime list, env) are properly documented.
97-122: LGTM!The new sandbox create options are well-documented with clear descriptions. The examples effectively demonstrate common use cases including port exposure and project association. Note: Line 97 has the same
python:3.14version concern flagged earlier.
145-158: LGTM!The list command options are comprehensive with clear status filter values and pagination support. The examples effectively show filtering by status and project.
234-370: LGTM!The expanded File Operations section is comprehensive and well-structured. Each command (files/lsf, mkdir, rm, rmdir, download/dl, upload/ul) is clearly documented with options, aliases, and practical examples.
443-542: LGTM!The snapshot build documentation is excellent. The build file format section with YAML examples, glob patterns, environment variable substitution, and the helpful callout tip provide clear guidance for users creating reproducible snapshot definitions.
628-653: LGTM!The Runtime Commands section is clear and consistent with the documentation style used throughout. The pagination options and alias are properly documented.
681-685: LGTM!The Next Steps section provides clear navigation to related documentation with updated paths that align with the Services reorganization.
content/index.mdx (1)
39-39: LGTM!The link path update from
/Sandboxto/Services/Sandboxcorrectly aligns with the restructured documentation hierarchy in this PR.content/Services/Sandbox/snapshots.mdx (5)
8-23: LGTM!The introductory section clearly explains the snapshot workflow and layering concept (runtime → dependencies → files). Cross-references to SDK and CLI documentation use the correct new paths.
33-91: LGTM!The declarative snapshots section is comprehensive with clear YAML examples, build options, and a helpful comparison table. The file exclusion patterns correctly demonstrate negation syntax.
92-110: LGTM!The manual snapshot creation workflow is clearly documented with a logical sequence: create sandbox → install dependencies → save snapshot → cleanup.
149-208: LGTM!The CLI commands section provides comprehensive coverage of snapshot management operations with clear examples for each command.
297-302: LGTM!Best practices are practical and the next steps links use the correct updated paths.
content/Services/Sandbox/sdk-usage.mdx (5)
172-174: LGTM!The callout clearly explains snapshot semantics and links to the correct documentation path.
271-277: LGTM!The expanded list options with
projectId,snapshotId, andoffsetprovide useful filtering and pagination capabilities.
311-327: LGTM!The SandboxCreateOptions table is well-documented with the new
runtime,name,description, andmetadatafields. The type definitions and examples are clear.
338-350: LGTM!The new
Executiontype documentation clearly describes the return structure fromsandbox.execute(), including the stream URLs for stdout/stderr access.
361-372: LGTM!The best practices section with the internal anchor link and updated next steps paths maintains good documentation navigation.
content/Services/Sandbox/index.mdx (7)
8-15: LGTM!The "Three Ways to Use Sandboxes" table provides a clear overview of the different access methods with appropriate links.
20-33: LGTM!The Key Concepts section clearly establishes the Runtime → Sandbox → Snapshot progression with a practical step-by-step workflow.
34-63: LGTM!The Runtimes section effectively categorizes Language and Agent runtimes with clear descriptions. The CLI command tip for listing available runtimes is helpful.
65-78: LGTM!The Snapshots overview provides a concise summary with an appropriate link to the detailed documentation, avoiding duplication.
128-136: LGTM!The SDK Access section is clear and concise, establishing the consistent API across Agents and Routes contexts.
171-175: LGTM!The Next Steps links correctly point to the updated documentation paths for SDK Usage, Snapshots, and CLI Commands.
137-150: The'python:3.14'runtime example is correct. Python 3.14 was released on October 7, 2025, making it a valid, stable version. No changes needed.Likely an incorrect or invalid review comment.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
content/Reference/CLI/deployment.mdx
Outdated
| ```json | ||
| { | ||
| "deployment": { | ||
| "resources": { | ||
| "cpu": "500m", | ||
| "memory": "512Mi", | ||
| "disk": "1Gi" | ||
| }, | ||
| "domains": [] | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| Use the configuration file for domains that should persist across deployments. Use CLI commands for quick testing or temporary domains. | ||
| **Defaults:** `cpu: "500m"`, `memory: "500Mi"`, `disk: "500Mi"` |
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.
Memory value inconsistency between example and defaults.
The JSON example shows "memory": "512Mi" (line 321) but the defaults text states memory: "500Mi" (line 329). Please align these values to avoid confusion about the actual default.
📝 Suggested fix
Either update the example to match defaults:
"resources": {
"cpu": "500m",
- "memory": "512Mi",
+ "memory": "500Mi",
"disk": "1Gi"
},Or, if 512Mi is intentional as an example of customization, consider adding a comment or note clarifying that this differs from the default.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ```json | |
| { | |
| "deployment": { | |
| "resources": { | |
| "cpu": "500m", | |
| "memory": "512Mi", | |
| "disk": "1Gi" | |
| }, | |
| "domains": [] | |
| } | |
| } | |
| ``` | |
| Use the configuration file for domains that should persist across deployments. Use CLI commands for quick testing or temporary domains. | |
| **Defaults:** `cpu: "500m"`, `memory: "500Mi"`, `disk: "500Mi"` |
🤖 Prompt for AI Agents
In `@content/Reference/CLI/deployment.mdx` around lines 316 - 329, The JSON
example's "memory" value ("512Mi" in the deployment example object) conflicts
with the documented Defaults line (`memory: "500Mi"`); update either the
example's "memory" field to "500Mi" to match the Defaults, or change the
Defaults text to "512Mi" if that is the true default, or add a clarifying note
that the example uses a custom memory value; adjust the "memory" value or the
Defaults text accordingly and ensure the keys `"memory"` and the Defaults
sentence remain consistent.
Summary by CodeRabbit
Documentation
New Features
✏️ Tip: You can customize this high-level summary in your review settings.