chore: bump software-agent-sdk for portable agent-server runtime#612
chore: bump software-agent-sdk for portable agent-server runtime#612simonrosenberg wants to merge 2 commits intomainfrom
Conversation
all-hands-bot
left a comment
There was a problem hiding this comment.
Taste Rating: 🟡 Acceptable approach, but premature
[CRITICAL ISSUES]
🔴 Dependency on unmerged code: You're bumping to commit b32e1c74 from SDK PR #2676, which is still open and unmerged. This violates basic stability principles. What happens when that PR changes? What if it never merges? Don't point production infrastructure at moving targets.
🟠 Missing evidence in THIS repo: Your validation section says "verified in the SDK PR" - that's not good enough. You're changing a submodule in the benchmarks repo, so show me that the benchmarks still work. Run terminalbench-infer, swebench-infer, or whatever uses this agent-server code and prove it doesn't break. Upstream tests don't count as proof your integration works.
[IMPROVEMENT OPPORTUNITIES]
🟡 Evidence Section: Add concrete proof that commit0 (or another affected benchmark) now works end-to-end with this change. A command + output showing a successful run would make this reviewable.
VERDICT:
⏸️ Wait for upstream, then validate locally
KEY INSIGHT:
Solving a real problem (good), but pointing to unmerged upstream code breaks the "reproducible builds" principle this repo values. Merge the SDK PR first, then bump to a stable commit.
|
Added repo-local validation and updated the submodule bump to the latest SDK branch head ( Benchmarks-local validation run in this repo:
The remaining process blocker from the review still stands: this PR should be repointed to the merged |
|
We fixed the core issue with #614 |
Summary
vendor/software-agent-sdkto include the Docker portability fix for commit0 source images/agent-serverself-contained across base imagesProblem
Since SDK v1.15.0 (Mar 26), the agent-server Dockerfile builds a venv with symlinks to
/usr/local/bin/python3(from the builder'spython:3.13-bookworm). Commit0 base images are Ubuntu 22.04 with Python at/usr/bin/python3, so the container fails to start:This causes all commit0 runtime pods to get stuck in pending — kubelet can't start the container.
Fix
The SDK fix (OpenHands/software-agent-sdk#2676) bundles the Python runtime into
/agent-server/.python/and repoints venv symlinks, making the image portable across any base image.Validation
uv run pytest tests/agent_server/test_docker_build.py -qsource-minimalbuild againstdocker.io/wentingzhao/wcwidth:v0and a runtime import smoke testdocker.io/wentingzhao/tinydb:v0— container starts, Python resolves correctlyDepends on: OpenHands/software-agent-sdk#2676
Fixes #607