github.com/OpenHands/OpenHands/…/90159417350 - heads up release please is failing, so our process to cut a release is blocked i can take a look tmrw and if someone else wants to jump on this feel free to

I'm looking inside 🙂

Did 1.7.0 exist before? I seem to vaguely recall, last we looked into tag names conflicts, that they were not forced immutable on openhands/openhands repo, so it seemed possible to rename/retag the legacy tags with e.g. 1.x-legacy and tag the exact new hashes (that are more likely to matter in practice)

I examined with an agent and then checked the content, the below seems plausible: --- Vasco’s diagnosis and tag target are correct. I’d approve the repair with one operational change: don’t rely on racing to cancel publishing workflows. • Thefailed jobexplicitly searched for`v1.6.1`, found no release/tag, synthesized that name from the manifest, and GitHub rejected it as`previous_tag_name`. • `aaefde6…`is the correct target: it is the replayed equivalent of Agent Canvas’s original`v1.6.1` release, with the same tree and release commit message. • `last-release-sha`is independently broken:`10ce762…`exists only in the source Agent Canvas history. Its replayed SHA is`1294b089…`. I recommend removing the override once the tag is restored; it is not the direct cause of the 400. • Engel’s memory is right: a legacy`1.7.0` releasealready exists from May 1. Git itself distinguishes`1.7.0`from`v1.7.0`, but release-please compares the parsed semantic version and iterates releases newest-first, so the future`v1.7.0`wins only because it will be newer. That is a real latent ambiguity, but not today’s blocker. (parser,matching logic) The risky part is “push, then cancel both runs.” A

v1.6.1

push triggers the Docker and npm publishing workflows. Cancellation is a race against external publication. Recommended sequence 1. Prepare a PR removing the invalid`last-release-sha`, but do not merge it yet.

repo="OpenHands/OpenHands"
branch="fix/release-please-migration-baseline"

gh repo clone "$repo" OpenHands-release-fix
cd OpenHands-release-fix
git switch -c "$branch"

config_tmp="$(mktemp)"
jq 'del(."last-release-sha")' release-please-config.json >"$config_tmp"
mv "$config_tmp" release-please-config.json

git diff --check
git diff -- release-please-config.json
git add release-please-config.json
git commit -m "fix: remove stale release-please SHA"
git push -u origin "$branch"

pr_url="$(
  gh pr create \
    --repo "$repo" \
    --base main \
    --head "$branch" \
    --title "fix: remove stale release-please SHA" \
    --body "Remove the Agent Canvas source SHA that does not exist in the replayed OpenHands history. The missing v1.6.1 tag will be restored separately before this PR is merged."
)"

Get the PR approved and green, but leave it open until the tag has been restored. 2. Confirm the intended commit and ensure the tag does not already exist.

release_sha="aaefde6e7b23c0347824b31869de6e9982fdc839"
tag="v1.6.1"

gh api "repos/$repo/commits/$release_sha" \
  --jq '{sha: .sha, subject: (.commit.message | split("\n")[0])}'

gh api \
  -H "Accept: application/vnd.github.raw+json" \
  "repos/$repo/contents/package.json?ref=$release_sha" |
  jq -e '.version == "1.6.1"'

if gh api "repos/$repo/git/ref/tags/$tag" --jq '.object.sha' 2>/dev/null; then
  echo "STOP: $tag already exists; verify its SHA instead of recreating it."
  exit 1
fi

3. Temporarily disable only the two imported tag-publishing workflows. Resolve them by path because the repository currently has two workflows named “Docker.”

docker_workflow_id="$(
  gh workflow list --repo "$repo" --all --limit 100 --json id,path \
    --jq '.[] | select(.path == ".github/workflows/docker.yml") | .id'
)"

npm_workflow_id="$(
  gh workflow list --repo "$repo" --all --limit 100 --json id,path \
    --jq '.[] | select(.path == ".github/workflows/npm-publish.yml") | .id'
)"

test -n "$docker_workflow_id"
test -n "$npm_workflow_id"

test "$(
  gh api "repos/$repo/actions/workflows/$docker_workflow_id" --jq .state
)" = "active"

test "$(
  gh api "repos/$repo/actions/workflows/$npm_workflow_id" --jq .state
)" = "active"

Use a shell trap so the workflows are re-enabled even if tag creation fails:

reenable_publish_workflows() {
  gh workflow enable "$docker_workflow_id" --repo "$repo" || true
  gh workflow enable "$npm_workflow_id" --repo "$repo" || true
}

trap reenable_publish_workflows EXIT

gh workflow disable "$docker_workflow_id" --repo "$repo"
gh workflow disable "$npm_workflow_id" --repo "$repo"

gh api --method POST "repos/$repo/git/refs" \
  -f ref="refs/tags/$tag" \
  -f sha="$release_sha"

tag_sha="$(
  gh api "repos/$repo/git/ref/tags/$tag" --jq '.object.sha'
)"
test "$tag_sha" = "$release_sha"

reenable_publish_workflows
trap - EXIT

This creates a lightweight

v1.6.1

tag without racing to cancel Docker or npm publication. GitHub also documents the `gh workflow disable`/`enable` procedure. 4. Merge the configuration PR. This main-branch push should trigger release-please after both repairs are present.

gh pr checks "$pr_url" --watch
gh pr merge "$pr_url" --repo "$repo" --squash --delete-branch

merge_sha="$(
  gh pr view "$pr_url" --repo "$repo" \
    --json mergeCommit --jq '.mergeCommit.oid'
)"

Find and watch the resulting release run:

release_run_id=""

for attempt in $(seq 1 30); do
  release_run_id="$(
    gh run list \
      --repo "$repo" \
      --workflow release.yml \
      --commit "$merge_sha" \
      --event push \
      --limit 1 \
      --json databaseId \
      --jq '.[0].databaseId'
  )"

  test -n "$release_run_id" && break
  sleep 2
done

test -n "$release_run_id"
gh run watch "$release_run_id" --repo "$repo" --compact --exit-status

If it fails, retrieve only the failing logs:

gh run view "$release_run_id" --repo "$repo" --log-failed

Finally, confirm release-please opened the expected draft PR:

gh pr list \
  --repo "$repo" \
  --state open \
  --head release-please--branches--main \
  --json number,title,isDraft,url

The expected title is

chore(main): release 1.7.0

. 5. Treat the legacy`1.7.0`release/tag ambiguity as a separate migration task. Do not move or delete published tags during this incident. Create a follow-up issue instead:

gh issue create \
  --repo "$repo" \
  --title "Disambiguate legacy and Agent Canvas 1.x release tags" \
  --body "OpenHands has legacy unprefixed 1.x releases while Agent Canvas uses v-prefixed 1.x tags. release-please compares parsed semantic versions, so these are logically ambiguous even though the Git refs differ. Inventory affected releases and design a compatibility-preserving migration before changing any published tags."

github.com/OpenHands/OpenHands/pull/16133/changes Starting the fix procedure for release please For now, disabling the release CI on tag push to prevent accidental releases

Oh, I no longer have write access with the repo change

Approved!

github.com/OpenHands/OpenHands/…/v1.6.1 Tagged new target commit and copied over the release note as well

This is Github being slow in marking it latest?

Hmm possibly, i'll double check

ah 🥲

not verified?

oh i simply didn't mark it as the latest, its a boolean flag