utils(release): Fix poetry lock conflict and move openhands-cli step earlier

[xingyaoww]

Summary

This PR fixes the failing GitHub Actions workflow (https://github.com/OpenHands/software-agent-sdk/actions/runs/21639490412/job/62374987438) and reorders the version bump steps.

The Problem

The workflow was failing with:

Cannot enrich dependency with incompatible constraints: openhands-agent-server (==1.11.0) and openhands-agent-server (==1.10)

This happened because poetry add updates both pyproject.toml AND poetry.lock, and then the subsequent poetry lock tried to resolve constraints between the partially updated lock file and the new specs.

The Fix

1. Use poetry add --lock - Only updates pyproject.toml without modifying the lock file, avoiding constraint conflicts

2. Use poetry lock --no-update - Regenerates lock files cleanly from the updated pyproject.toml specs without trying to update other dependencies

Additional Change

3. Move OpenHands-CLI PR creation step before OpenHands PR step - As requested, since it's simpler (uses uv add directly) and less error-prone than the OpenHands step which involves poetry operations in both root and enterprise directories.

@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:95bfc91-python

Run

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

All tags pushed for this build

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

About Multi-Architecture Support

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

[all-hands-bot]

Overall the reordering and error handling improvements look good, but there are concerns about the Poetry command changes that need verification.

Key Issues

🟠 Important: Poetry --lock Flag Behavior (Lines 224, 229)

The PR description states that --lock "Only updates pyproject.toml without modifying the lock file", but according to Poetry documentation, --lock actually means "Do not perform install (only update the lockfile)".

This means poetry add --lock DOES update both pyproject.toml AND poetry.lock (it just skips the installation step).

Concern: If poetry add --lock already updates poetry.lock, then the subsequent poetry lock --no-update calls (lines 235, 240) might be redundant or could potentially cause issues.

Action needed: Please verify that this combination actually resolves the original constraint conflict. Consider testing whether:

1. The workflow succeeds with these changes
2. Whether the poetry lock --no-update calls are actually necessary, or if poetry add --lock alone is sufficient

🟡 Suggestion: Update Comments (Lines 222, 227)

The inline comments should accurately reflect what --lock does:

• Current: # Use --lock to only update pyproject.toml without modifying lock file
• Should be: # Use --lock to update pyproject.toml and poetry.lock without installing packages

🟡 Suggestion: Clarify Lock File Regeneration (Lines 234, 239)

The comments say "regenerate from scratch" but poetry lock --no-update doesn't regenerate from scratch - it updates the lock file based on current pyproject.toml constraints while keeping existing package versions where possible.

If you truly need to regenerate from scratch, you'd need to remove the lock file first. However, --no-update is likely correct here since you want to lock the specific versions you just added without updating other dependencies.

🟢 Nit: Add Explanatory Comment (Line 139)

Consider adding a comment explaining why OpenHands-CLI runs first, as mentioned in the PR description:

# OpenHands-CLI step runs first since it uses uv (simpler) rather than poetry
- name: Create PR for OpenHands-CLI repo

🟢 Nit: Consistency in Change Detection (Line 162)

Good defensive programming to check for no changes in the OpenHands-CLI step! Consider adding the same check to the OpenHands repo step for consistency (though it may always have changes due to the hash update).

Summary

The reordering of steps makes sense, but please verify the Poetry command behavior matches expectations. The combination of poetry add --lock followed by poetry lock --no-update may or may not be the optimal solution depending on what these commands actually do in your Poetry version.