Fix Python selection in version-bump PR workflow

[neubig]

Summary

• use Python 3.12 explicitly when updating OpenHands-CLI in the version-bump workflow
• keep the existing OpenHands repo flow unchanged
• prevent release follow-up PR creation from failing when a downstream repo pins Python 3.12

Context

The v1.14.0 release triggered a failure in the Create Version Bump PRs workflow because the OpenHands-CLI step ran uv add with Python 3.13 against a repo that declares requires-python = "==3.12.*".

Failed run: https://github.com/OpenHands/software-agent-sdk/actions/runs/23070949770

Testing

• uv run pre-commit run --files .github/workflows/version-bump-prs.yml

---

Agent Server images for this PR

• GHCR package: https://github.com/OpenHands/agent-sdk/pkgs/container/agent-server

Variants & Base Images

Variant	Architectures	Base Image	Docs / Tags
java	amd64, arm64	eclipse-temurin:17-jdk	Link
python	amd64, arm64	nikolaik/python-nodejs:python3.13-nodejs22	Link
golang	amd64, arm64	golang:1.21-bookworm	Link

Pull (multi-arch manifest)

# Each variant is a multi-arch manifest supporting both amd64 and arm64
docker pull ghcr.io/openhands/agent-server:256e9c9-python

Run

docker run -it --rm \
  -p 8000:8000 \
  --name agent-server-256e9c9-python \
  ghcr.io/openhands/agent-server:256e9c9-python

All tags pushed for this build

ghcr.io/openhands/agent-server:256e9c9-golang-amd64
ghcr.io/openhands/agent-server:256e9c9-golang_tag_1.21-bookworm-amd64
ghcr.io/openhands/agent-server:256e9c9-golang-arm64
ghcr.io/openhands/agent-server:256e9c9-golang_tag_1.21-bookworm-arm64
ghcr.io/openhands/agent-server:256e9c9-java-amd64
ghcr.io/openhands/agent-server:256e9c9-eclipse-temurin_tag_17-jdk-amd64
ghcr.io/openhands/agent-server:256e9c9-java-arm64
ghcr.io/openhands/agent-server:256e9c9-eclipse-temurin_tag_17-jdk-arm64
ghcr.io/openhands/agent-server:256e9c9-python-amd64
ghcr.io/openhands/agent-server:256e9c9-nikolaik_s_python-nodejs_tag_python3.13-nodejs22-amd64
ghcr.io/openhands/agent-server:256e9c9-python-arm64
ghcr.io/openhands/agent-server:256e9c9-nikolaik_s_python-nodejs_tag_python3.13-nodejs22-arm64
ghcr.io/openhands/agent-server:256e9c9-golang
ghcr.io/openhands/agent-server:256e9c9-java
ghcr.io/openhands/agent-server:256e9c9-python

About Multi-Architecture Support

• Each variant tag (e.g., 256e9c9-python) is a multi-arch manifest supporting both amd64 and arm64
• Docker automatically pulls the correct architecture for your platform
• Individual architecture tags (e.g., 256e9c9-python-amd64) are also available if needed

[github-actions]

API breakage checks (Griffe)

Result: Passed

Action log

[github-actions]

Agent server REST API breakage checks (OpenAPI)

Result: Failed

Log excerpt (first 1000 characters)

::error title=openhands-agent-server REST API::Breaking REST API change detected without MINOR version bump (1.14.0 -> 1.14.0).

Breaking REST API changes detected compared to baseline release:
- added '#/components/schemas/ACPAgent-Output, #/components/schemas/Agent-Output' to the '/items/anyOf[subschema #1: ConversationInfo]/agent' response property 'oneOf' list for the response status '200'
- the '/items/anyOf[subschema #1: ConversationInfo]/agent' response's property type/format changed from 'object'/'' to ''/'' for status '200'
- removed the required property '/items/anyOf[subschema #1: ConversationInfo]/agent/kind' from the response with the '200' status
- removed the required property '/items/anyOf[subschema #1: ConversationInfo]/agent/llm' from the response with the '200' status
- the 'agent' request property type/format changed from 'object'/'' to ''/''
- added '#/components/schemas/ACPAgent-Output, #/components/schemas/Agent-Output' to the 'agent' response property 'oneOf' li

Action log

[all-hands-bot]

🟢 Good taste - This is how you fix a problem.

The downstream repo requires Python 3.12, so you specify Python 3.12. No over-engineering, no special cases. The comment explains why, which is exactly what you want for maintainability.

✅ Worth merging

KEY INSIGHT: Pragmatic fix that directly addresses the production constraint without introducing complexity. The explicit comment documents the dependency, making it easy to update when OpenHands-CLI supports newer Python versions.

[enyst]

@OpenHands Read all comments. OpenAPI checks failed, but not from this PR. From what PR did they start to fail?

[openhands-ai]

I'm on it! enyst can track my progress at all-hands.dev

[enyst]

I traced this to PR #2190: Enable ACPAgent on RemoteRuntime API (merge commit ca621a42). That PR's own Agent server REST API breakage checks (OpenAPI) comment already failed with the same signature:

• added ACPAgent-Output / Agent-Output to the agent schema
• changed agent from a plain object to a oneOf union
• removed required fields like kind and llm from the old shape

So this PR is just inheriting a pre-existing failure from main; it did not introduce the OpenAPI change.

For reference, PR #2423 passed its OpenAPI check because that branch did not include the ACPAgent API change yet, even though it merged later.