ci(release): auto-create GitHub Release after PyPI publish#57
Merged
Conversation
Adds a `create-release` job to `python-publish.yml` that runs after
`publish-to-pypi` succeeds and creates a GitHub Release with body
extracted from the corresponding CHANGELOG.md section.
Eliminates the manual `gh release create` step every release. Previously,
v0.4.0 → v0.4.1 each required a separate manual release-creation pass
after the tag-triggered PyPI publish.
Behavior:
- Triggered by tag push only (not manual workflow_dispatch republishes).
- Extracts the CHANGELOG section between `## [VERSION]` and the next
`## [` heading using a portable string-based awk script (no regex
escaping issues across awk variants).
- If no CHANGELOG entry is found for the version, falls back to a generic
"see commit history" body — does not fail the job.
- Title is the tag name (e.g. `v0.4.1`); the descriptive suffix on prior
releases ("v0.4.0 — Dynamic subject and action fields...") is convention,
not required, and the user can edit titles after the fact.
- `prerelease: ${{ contains(github.ref_name, '-') }}` flags any tag with
a hyphen (e.g. `v0.5.0-rc.1`) as prerelease automatically.
Pinned action SHAs:
- softprops/action-gh-release@b430933... (v3.0.0)
- actions/checkout@de0fac2... (v6, matches existing job)
Permissions:
- `contents: write` on this job only; default `contents: read` preserved
for the workflow-level minimum.
Tested locally:
- Successful extraction for v0.4.1 produces clean body (CHANGELOG section
without heading or next-version boundary).
- Missing version (e.g. v9.9.9) takes the fallback path without erroring.
This means future releases will be one-step: `git tag vX.Y.Z` + `git
push origin vX.Y.Z` and the workflow handles both PyPI publish and
GitHub Release creation.
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
1 participant
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.
Summary
Adds a
create-releasejob topython-publish.ymlthat runs afterpublish-to-pypisucceeds and creates a GitHub Release with body extracted from the correspondingCHANGELOG.mdsection.Eliminates the manual
gh release createstep every release. v0.4.1 had to be created manually because the workflow only handled PyPI publish; this PR closes that loop.How it works
v*) triggers the workflow as before —build→publish-to-pypi.create-releaseruns after PyPI publish succeeds (only on tag push, not on manualworkflow_dispatch).softprops/action-gh-release@v3.0.0with the extracted body.Tested locally
## [0.4.1]and## [0.4.0], no heading bleed"Release v9.9.9. See commit history for changes."— does not fail the jobEdge cases handled
v0.5.0-rc.1) → auto-detected viacontains(github.ref_name, '-'), marked as prerelease in GitHub.workflow_dispatch→create-releaseskipped (only runs on tag push).Permissions
contents: readpreserved at workflow level.contents: writegranted only on thecreate-releasejob.Action SHAs (pinned per the existing convention)
softprops/action-gh-release@b4309332981a82ec1c5618f44dd2e27cc8bfbfda(v3.0.0, latest stable)actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd(v6, matches existing jobs)Test plan
v*tag push). The first real exercise will be whatever 0.4.2 or 0.5.0 ships next.v0.4.2-test.1prerelease tag → workflow should publish to PyPI and create a prerelease GitHub Release. Yank from PyPI after if needed.After this lands
Future releases collapse to one step: bump version + CHANGELOG entry on a PR, merge, then
git tag vX.Y.Z && git push origin vX.Y.Z. PyPI + GitHub Release both happen automatically.