https://docs.all-hands.dev/ logo
Join Slack
Powered by
Pr for new release process using please-release-ac...
# proj-agent
m
Pr for new release process using please-release-action. https://github.com/OpenHands/software-agent-sdk/pull/3939 how it works: • Create a draft PR to track all incoming PRs for the release. • When ready to release, mark this PR as "ready for review." • This automatically adds labels to run integration, examples, and behavior tests. • The standard release checklist is included in the PR description. • Merging this PR triggers the new release. ⚠️ IMPORTANT: Anything merged between marking it "ready for review" and the final merge will be included in the release, as I couldn't find a way to freeze the branch. @calm-artist-7206 @chilly-france-44439 Could you double check that I'm not missing something? Thanks 🙂
c
overall LGTM!
⚠️ IMPORTANT: Anything merged between marking it "ready for review" and the final merge will be included in the release, as I couldn't find a way to freeze the branch.
wondering if we could just add another CI to enforce this, or just fix the upstream release workflow
m
We can freeze the branch. Actually, we have to create another branch and merge from there. This PR enable that: https://github.com/OpenHands/release-actions/pull/18 then once the frozen release branch is merged -> the chore(main) branch is automatically updated with the new version number cc @calm-artist-7206
if someone can give a look 🙂 Then I can update the PR above
c
Just the quickest question: in Joe L.’s readme on release-please, there was something about freeze, is this PR aware of that or adding something parallel, or am I hallucinating worse than my LLM?
m
We can just use the existing soak/freeze flow (https://github.com/OpenHands/release-actions#freezing-a-release-to-soak) no code changes needed. To freeze a release: • git branch release/1.31 main && git push origin release/1.31 • release-please opens the release PR on that branch; mark it ready → tests/labels/Slack fire as usual → merge to publish → merge release/1.31 back to main. From the moment you branch, main can keep moving and none of it lands in the release. My freeze-on-ready PR uses the same mechanism, it only adds (1) triggering the branch-cut automatically from the "mark ready" click and (2) locking the 
chore(main)
PR so nobody accidentally releases from main's tip. If we're fine cutting the branch by hand, we don't need it. I'd close the PR.
c
If we’re fine cutting the branch by hand
… I… don’t think so? Do you mean like in the Before Times (tm), when the human went to open a new terminal tab and type commands? 😅 😊 The agent instructions matter imho, I think maybe humans will be better off to not have to relearn how to keep it on track
your freeze-on-ready pr behavior sounds exactly right!
👍 1
m
Could you review the pr?:)
👀 1
🙏 1
c
Relatively related: I think Slack doesn’t work because the Slack token doesn’t exist on the repo?
What if we structure the agent skill such that it has two sections, like • human release workflow • agent release workflow And we can review those and make sure they’re accurate, and point then the humans to it, and the agent can also help them understand it?
Or maybe there are four now, since post merge with release-please now we need to do more things: • prepare release workflow ◦ for humans ◦ for agents • merge release workflow ◦ for humans ◦ for agents
cc @able-napkin-92802 Just so you know, the new PR on adapting release came from this discussion.
ty 1
m
What if we structure the agent skill such that it has two sections, like
which skill are you speaking of?
c
prepare release
2 Views
Open in Slack
PreviousNext
Powered by