chore: create a GitHub Release on every tagged publish

[hampsterx]

Summary

• Make a GitHub Release a default part of every release, not a step to remember: after a successful PyPI publish, publish.yml creates a Release for the tag with notes auto-generated from the merged PRs since the previous tag.
• Grant the publish job contents: write (needed to create the release); it already had id-token: write for OIDC.
• Pin every GitHub Action ref to a full commit SHA (with # vX.Y.Z comments) in both publish.yml and ci.yml, since the publish job now carries write scope. Dependabot manages the bumps.
• The release step is idempotent and tolerant of a concurrent create, and runs only after publish succeeds.
• Document the new step and the "edit notes afterwards / hand-write the first release" guidance in RELEASING.md.

Backwards compatibility

CI/release workflow only. No package or API change.

Test plan

• publish.yml and ci.yml parse as valid YAML; check-yaml clean
• All action refs pinned to SHAs (no remaining @vN / @release/ refs)
• Release step guarded against pre-existing and concurrently-created releases
• Exercised on the next tag push (logic mirrors the manually-created v0.1.0 release)

[coderabbitai]

📝 Walkthrough

Walkthrough

The publish job in .github/workflows/publish.yml gains contents: write permission and a new post-publish step that idempotently creates a GitHub Release for the pushed tag using gh release view to check existence and gh release create --verify-tag --generate-notes to create it. RELEASING.md documents this new automated step.

Changes

Automated GitHub Release on publish

Layer / File(s)	Summary
Workflow permission and release creation step .github/workflows/publish.yml, RELEASING.md	contents: write is added to the publish job permissions. A new step after PyPI publication uses gh release view to check if a release already exists for the tag; if not, it calls gh release create --verify-tag --generate-notes. RELEASING.md documents this automated step and notes that the first release requires manually written notes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐇 A tag gets pushed, the workflow hops,
Checks if a release exists — then stops!
If none is found, it conjures one new,
With notes auto-spun from commits' review.
No manual clicking, just merge and go —
The bunny approves this CI flow! 🎉

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: automating GitHub Release creation on tagged publishes, which aligns with the primary objective of the PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/auto-github-release

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/publish.yml:
- Around line 92-95: The race condition exists because another concurrent run
can create the release between the if check and the gh release create command.
Fix this by making the gh release create command itself tolerant to concurrent
creation instead of relying on the check. Modify the gh release create "$tag"
--verify-tag --generate-notes command to either suppress errors when the release
already exists or add conditional logic that continues silently if the release
is already present by the time the create command executes, eliminating the time
gap where concurrent runs can interfere.
- Line 64: The publish workflow job grants `contents: write` permission but uses
mutable action references. Replace the three action refs (actions/checkout@v6,
actions/setup-python@v6, and pypa/gh-action-pypi-publish@release/v1) with their
full 40-character commit SHAs to prevent security risks if these actions are
compromised. Look up the current commit SHA for each action version and pin each
action reference to its corresponding SHA format.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: c84674b1-9748-4645-ae93-e86375bb4d09

📥 Commits

Reviewing files that changed from the base of the PR and between ad1c191 and 18fd29d.

📒 Files selected for processing (2)

• .github/workflows/publish.yml
• RELEASING.md