image.png

sorry, I forgot that we still had that step, let’s cut a release

also, would it be possible to automate that step with ci?

I’m going to be talking at c3 very soon so it’d be great if you could do it quicky

@nutritious-balloon-65098 can you check if we can automatically create a GitHub release whenever we merge the release PR into main?

Summary The user asked whether we can automatically create a GitHub release whenever a release PR is merged into main. The answer is yes, and I implemented it. What was done 1. Created

.github/workflows/create-release.yml

— a new workflow that: ◦ Triggers on

pull_request: closed

targeting

main

◦ Only runs when the PR is merged AND the branch starts with

rel-

(matching the

prepare-release.yml

convention) ◦ Extracts the version from the branch name (e.g.,

rel-1.19.1

→

1.19.1

) ◦ Checks if a release already exists (idempotent/safe to re-run) ◦ Creates a GitHub release with tag

vX.Y.Z

, targeting

main

, with auto-generated release notes ◦ This chains into the existing

pypi-release.yml

→

version-bump-prs.yml

pipeline 1. Updated

.github/workflows/prepare-release.yml

— the PR body template and summary now explain the automated post-merge flow instead of listing manual release creation steps. 2. Updated

.agents/skills/sdk-release/SKILL.md

— Phase 6 now documents the automated pipeline, and the checklist marks post-merge steps as (Automated). Checklist • Request fully addressed: auto-create GitHub release on release PR merge • Changes are concise: only 3 files touched, all directly related to the request • Pre-commit checks pass on all modified files • Changes committed locally Not yet done • The changes have not been pushed or a PR created — awaiting user confirmation on preferred workflow.

Summary The user asked whether we could automatically create a GitHub release when a release PR is merged into main, and then asked me to create a PR for it. What was done 1. Investigated the current release pipeline — identified the manual gap between merging the release PR and creating a GitHub release (which triggers PyPI publication). 2. Created

.github/workflows/create-release.yml

— a new workflow that: ◦ Triggers on

pull_request: closed

targeting

main

◦ Guards on

merged == true

and branch prefix

rel-

◦ Extracts and validates the version from the branch name ◦ Skips if a release already exists (idempotent) ◦ Creates a GitHub release with tag

v<version>

, targeting

main

, with auto-generated notes 1. Updated

.github/workflows/prepare-release.yml

— replaced the manual release creation checklist items in the PR body template with a "What happens on merge" section describing the automated pipeline. 2. Updated

.agents/skills/sdk-release/SKILL.md

— rewrote Phase 6 to document the automated pipeline and updated the checklist to mark post-merge steps as (Automated). 3. Pushed to branch

ci/auto-create-release-on-merge

and created PR #3023. Checklist • Request fully addressed — automated release creation on merge of

rel-*

PRs • Changes are concise — only the new workflow, the PR template update, and the skill doc update (all directly relevant) • No extraneous changes • Pre-commit checks pass on all modified files

Summary The user asked to automate GitHub release creation when a release PR is merged into main, and then asked me to create a PR for it. After the PR was created, the user pointed out that the release tag should not target

main

because other unreleased changes could land there first. What was done (since last summary) Fixed the

--target

in

create-release.yml

from

main

to

github.event.pull_request.merge_commit_sha

, ensuring the tag always points at exactly the release PR's merge commit — even if other PRs land on

main

before the workflow runs. This was pushed to the existing PR: https://github.com/OpenHands/software-agent-sdk/pull/3023 Checklist • User's feedback addressed: release tag now targets the merge commit SHA instead of

main

• Fix is minimal — single line change in the workflow file • Pre-commit checks pass • Committed and pushed to the open PR • No extraneous changes

Summary The user asked to automate GitHub release creation when a release PR is merged into main. Here's what was done: Changes Made 1. New workflow

.github/workflows/create-release.yml

— Triggers on

pull_request: closed

for

main

, guards on

merged == true

and

rel-*

branch prefix, extracts the version, and creates a GitHub release with: ◦ Tag

v<version>

targeting the merge commit SHA (not

main

) to avoid picking up unreleased changes if other PRs land first ◦

--notes-start-tag

set to the latest existing release tag, exactly replicating the "Previous tag" selection in the GitHub UI for auto-generated release notes ◦ Idempotency check to skip if the release already exists 1. Updated

.github/workflows/prepare-release.yml

— Release PR body template now describes the automated post-merge pipeline instead of listing manual release creation steps. 2. Updated

.agents/skills/sdk-release/SKILL.md

— Phase 6 rewritten to document the automated pipeline; checklist marks post-merge steps as (Automated). Checklist • Automate GitHub release creation on release PR merge • Target the merge commit SHA instead of

main

(per user feedback about race conditions) • Explicitly pass the previous release tag for release notes generation (per user feedback about matching GitHub UI behavior) • Update PR template and release skill docs to reflect the new flow • All pre-commit checks pass • PR created: https://github.com/OpenHands/software-agent-sdk/pull/3023 Conciseness All changes are directly related to the request — no extraneous modifications.

Summary The user asked whether we can automatically create a GitHub release when a release PR is merged into main. The answer is yes, and I implemented it. What was done 1. Created

.github/workflows/create-release.yml

— a new workflow that triggers on

pull_request: closed

targeting

main

, gated on the PR being merged and the branch matching

rel-*

. It: ◦ Extracts the version from the branch name (e.g.,

rel-1.19.1

→

1.19.1

) ◦ Checks if the release already exists (idempotent) ◦ Finds the previous release tag and passes it via

--notes-start-tag

(matching the GitHub UI's "Previous tag" behavior) ◦ Creates the release targeting the PR's merge commit SHA (not

main

, to avoid picking up unrelated commits) ◦

gh release create

also creates the lightweight tag

v<version>

at that commit, matching the existing tag convention 1. Updated

.github/workflows/prepare-release.yml

— the PR body template now explains the automated post-merge flow instead of listing manual release creation steps. 2. Updated

.agents/skills/sdk-release/SKILL.md

— Phase 6 now documents the automated pipeline, and the checklist marks post-merge steps as (Automated). Checklist of user feedback addressed • Automate GitHub release creation on release PR merge • Target the merge commit SHA instead of

main

(to avoid including unreleased changes) • Explicitly pass the previous release tag for auto-generated release notes (matching GitHub UI behavior) • Tag creation follows existing convention (lightweight tags created by

gh release create

) • PR created: https://github.com/OpenHands/software-agent-sdk/pull/3023 Changes are concise All three files changed are directly related to the request — the new workflow, the PR template that references it, and the release guide that documents it. No extraneous changes.

Summary The user asked to automate GitHub release creation when a release PR is merged into main, then asked me to test it end-to-end in a separate repo and post evidence to the PR. What was done 1. Created

.github/workflows/create-release.yml

— a new workflow that triggers on

pull_request: closed

for

main

, checks the PR was merged from a

rel-*

branch, extracts the version, finds the previous release tag, and creates a GitHub release with auto-generated notes. 2. Updated

.github/workflows/prepare-release.yml

— revised the PR body template and summary to reflect the automated post-merge flow (removed manual release creation checklist items). 3. Updated

.agents/skills/sdk-release/SKILL.md

— rewrote Phase 6 to document the automated pipeline and updated the checklist to mark post-merge steps as (Automated). 4. End-to-end tested in xingyaoww/release-exp — set up the repo, ran the full flow (prepare-release → merge PR → auto-create release), and confirmed everything works. Evidence posted as a comment on PR #3023. Checklist • Workflow auto-creates a GitHub release when a

rel-*

PR is merged • Tag targets the merge commit SHA (not

main

tip) to avoid including unreleased changes • Previous release tag is explicitly found and passed via

--notes-start-tag

for correct release notes • Lightweight tag created (matches existing convention) • Idempotent — skips if release already exists • PR template and release skill updated to reflect new automated flow • End-to-end test passed in xingyaoww/release-exp • Evidence posted to PR #3023 Changes are concise All three files changed are directly relevant — the new workflow, the updated PR template, and the updated release skill documentation. No extraneous changes.