fix: update enterprise/pyproject.toml before poetry lock in version bump workflow

[xingyaoww]

Summary

This PR fixes the failing PyPI release workflow that creates version bump PRs.

Problem

The workflow was failing with the error:

Cannot enrich dependency with incompatible constraints: openhands-agent-server (==1.10.0) and openhands-agent-server (==1.9.1)

See failed run: https://github.com/OpenHands/software-agent-sdk/actions/runs/21366085620/job/61499460469

Root Cause

When creating the version bump PR for the OpenHands repo, the workflow:

1. Updated pyproject.toml in the root with new SDK package versions
2. Ran poetry lock in the root directory
3. Then updated enterprise/pyproject.toml

However, step 2 failed because the enterprise/ directory has its own pyproject.toml that depends on the OpenHands SDK packages, and Poetry resolves dependencies across the entire project. Since enterprise/pyproject.toml still had the old version (1.9.1) while the root had the new version (1.10.0), Poetry couldn't resolve the conflicting constraints.

Solution

Update both pyproject.toml files (root and enterprise) before running poetry lock. This ensures there are no conflicting dependency constraints when Poetry resolves dependencies.

The workflow now:

1. Updates pyproject.toml in the root with new SDK package versions
2. Updates enterprise/pyproject.toml with new SDK package versions
3. Runs poetry lock in the root directory (now succeeds)
4. Runs poetry lock in the enterprise directory
5. Updates the AGENT_SERVER_IMAGE hash

Changes

• Modified .github/workflows/pypi-release.yml to update enterprise/pyproject.toml before running poetry lock
• Updated commit message and PR body to reflect the additional enterprise changes

@xingyaoww can click here to continue refining the PR

---

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:341244b-python

Run

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

All tags pushed for this build

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

About Multi-Architecture Support

• Each variant tag (e.g., 341244b-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., 341244b-python-amd64) are also available if needed

[all-hands-bot]

Code Review

The fix correctly addresses the root cause by updating both pyproject.toml files before running poetry lock. However, there are robustness and maintainability issues that should be addressed.

[all-hands-bot]

🟠 Important: The cd enterprise / cd .. pattern is fragile and error-prone.

Problems:

• If any command between the cd operations fails, the script continues in the wrong directory
• No verification that we return to the correct location
• Makes debugging harder

Better approach:

(cd enterprise && poetry add "openhands-sdk==$VERSION" "openhands-tools==$VERSION" "openhands-agent-server==$VERSION") || exit 1

The subshell (...) ensures we always return to the original directory, and || exit 1 provides error handling.

[all-hands-bot]

🟠 Important: Same fragile cd pattern here. Use a subshell for safety:

Suggested change

	cd ..
	(cd enterprise && poetry lock) || exit 1

[all-hands-bot]

🟠 Important: No error checking. If poetry add fails, the workflow continues and will fail later with a confusing error.

Add error checking:

poetry add "openhands-sdk==$VERSION" "openhands-tools==$VERSION" "openhands-agent-server==$VERSION" || exit 1

[all-hands-bot]

🟠 Important: Add error checking here too:

Suggested change

	poetry lock
	poetry lock || exit 1

If poetry lock fails, we should stop immediately rather than continue with an inconsistent state.

[all-hands-bot]

🟡 Suggestion: The numbered comments (# 1., # 2., etc.) are maintenance burden. Every time a step is added or removed, all subsequent numbers need updating.

The echo statements already provide clear context. Consider removing the numbers:

# Update versions in pyproject.toml using poetry (root)
echo "📝 Updating root pyproject.toml..."

[all-hands-bot]

🟡 Suggestion: This comment is verbose. The commit message and the fix itself make this clear.

Consider a more concise version:

# Update enterprise pyproject.toml (must be done before root poetry lock)

[enyst]

LGTM