Repository navigation
fix(benchmarking): make the SWE-Perf ActorTemplate deployable - #1889
Conversation
The swebench-astropy-7336 ActorTemplate cannot be deployed as shipped. Two independent problems: 1. `image: ""` — the field is empty with a comment saying to fill it in before deploying. There is no way to supply it without editing a tracked file, so every run dirties the tree (and the substrate version label derived from it). 2. The command points at `/opt/swebench/replay.py` and `/opt/swebench/astropy_trace.json`. Neither path exists. The image generator in https://github.com/gke-labs/sweperf writes the replay server to `/replay.py` and the trajectory to `/trace.json` at the image root — which is also the image's own ENTRYPOINT. Nothing in that repo produces `/opt/swebench/`, so the container exits immediately with "can't open file '/opt/swebench/replay.py'". Supply the image through a SWEPERF_IMAGE environment variable, substituted by workloads/deploy.sh alongside the existing template variables, and correct the two paths. Also documents the minimum sweperf commit (c30c0d6, 2026-09-21). The async HTTP execution API this benchmark drives landed 2026-08-31 and `execution_duration_ms` on 2026-09-21; images built earlier ship a replay.py with no HTTP server and fail on the client's first `GET /status`. Verified against a rebuilt image: a 21-step / 4-cycle run completes with 0 failures.
|
Max Smythe (@maxsmythe) This is a small fix to make swe-perf runnable OOTB. PTAL. This will help unblock the prowjob setup. |
|
LGTM. A few thoughts for later Haowei Cai (Roy) (@roycaihw):
|
|
Yes Parnika Mandewalkar (@pmandewalkar) we have plan to use multiple sweperf images and dynamically populate the template, instead of using one specific image as entry point. |
|
Haowei Cai (Roy) (@roycaihw) I think dynamically populating the template though substrate as an idea is getting abandoned. One of our earlier conversations resulted in us agreeing on a small lightweight script that'll generate those templates, and this removes any additional substrate overhead. Let me know if that is still ok; cc Nishanth Kotla (@Nishanth29) |
Discussed offline. We are still aligned that we need a benchmark entry point that "run actors that uses a distribution of all available sweperf trajectories" instead of what we have now ("run actors that uses this single sweperf trajectory") The implementation detail of how to generate the actor templates for all the available sweperf trajectories isn't critical. We can have a script to generate them on the fly, or checked-in if substrate maintainers are okay with that. |
Related: #1694
The
swebench-astropy-7336ActorTemplate can't be deployed as shipped:image: ""must be hand-edited into a tracked file before every run./opt/swebench/replay.pyand/opt/swebench/astropy_trace.json, which the sweperf image generator neverproduces. It writes
/replay.pyand/trace.jsonat the image root (alsothe image's ENTRYPOINT), so the container exits immediately.
This PR:
SWEPERF_IMAGEenv var, substituted byworkloads/deploy.shlike the other template variables;c30c0d6), since older images have noHTTP server and fail on the first
GET /status.Usage:
Verified on GKE with both gVisor and microVM worker pools: 30-minute sweperf
runs at 1 user, all 4 cycles, 0 failures.
bash -n; exercised end-to-end as above)