Repository navigation
ci(release): release automatically on every feat and fix - #22
Merged
Merged
Conversation
The release PR used to wait for someone to merge it, so a feat or fix could sit on main unreleased. The workflow now merges the release PR as soon as release-please opens or refreshes it. That merge is made with GITHUB_TOKEN, which does not start new workflow runs, so a second release-please step in the same job tags and publishes the release. If that step ever misses the merged PR, the next push to main tags it instead. A concurrency group queues overlapping runs so two cannot race on one release, and never cancels a run partway through. The README's Development section describes the new flow. Closes #21 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017PZwFoejyVocqgdjxs9ech
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #21
Why
release-please collected every merged
featandfixinto one standing release PR, and nothing was released until someone merged it by hand. #15 sat open while three changes waited behind it. Each releasable change should now ship on its own.Changes
.github/workflows/release-please.ymlid: release.proutput is set, and runsgh pr merge <number> --squash. The output is unset when nothing was releasable, as fordocsandcicommits, so the step is skipped for those.GITHUB_TOKENstarts no new workflow run, as release-please-action's README notes, so without this step nothing would tag the release until the next push. If it ever misses the merged PR, the next push tomaintags it anyway, because release-please releases any merged PR still labelledautorelease: pending.concurrencygroup (release-please,cancel-in-progress: false) makes overlapping runs queue, so they cannot race on one release PR, and never cancels a run partway through a release.README.md: the Development section describes the new flow.Known trade-off
The release PR gets no CI run, again because
GITHUB_TOKENevents start no workflows. It only changes version strings andCHANGELOG.md, and every commit it releases already passed CI in its own PR.Verification
actionlinton both workflows: 0 errors. It checks thesteps.release.outputs.prexpressions and thefromJSONcall. shellcheck wasn't installed, and the onerun:line is fully quoted.pytest: 50 passedclaude plugin validate . --strictpassesmain. This PR is acicommit, so merging it releases nothing and both new steps are skipped. The first real test is the nextfeatorfix.🤖 Generated with Claude Code
https://claude.ai/code/session_017PZwFoejyVocqgdjxs9ech
Generated by Claude Code