feat: automated release workflow (version check + PyPI publish)#109
Open
GabrielBG0 wants to merge 6 commits into
Open
feat: automated release workflow (version check + PyPI publish)#109GabrielBG0 wants to merge 6 commits into
GabrielBG0 wants to merge 6 commits into
Conversation
|
Warning Review limit reached
More reviews will be available in 48 minutes and 59 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe PR replaces manual GitHub release triggering with a fully automated release pipeline. On every push to ChangesAutomated Release Pipeline
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
… workflow Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
.github/workflows/auto-release.yml (1)
28-31: ⚡ Quick winConsider disabling uv caching in this publish workflow.
astral-sh/setup-uvenables caching by default. For a privileged release/publish job, a poisoned cache could influence the built and published artifacts. Disabling the cache here removes that vector at negligible cost.♻️ Proposed change
- name: Install uv uses: astral-sh/setup-uv@d4b2f3b6ecc6e67c4457f6d3e41ec42d3d0fcb86 # v5.4.2 with: python-version: "3.10" + enable-cache: false🤖 Prompt for 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. In @.github/workflows/auto-release.yml around lines 28 - 31, The "Install uv" step using astral-sh/setup-uv@d4b2f3b6ecc6e67c4457f6d3e41ec42d3d0fcb86 currently enables caching by default; disable caching for this privileged release job by adding the cache parameter to the step (e.g., add under the with: block for the "Install uv" step — python-version: "3.10" — a cache: false entry) so the action runs without using or writing a cached UV installation.
🤖 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/auto-release.yml:
- Line 57: The current LATEST assignment uses "gh release list --limit 1" which
picks the most recent release by date, not the highest semver; change the
command that sets the LATEST variable so it fetches all release tag names and
determines the highest semver explicitly (e.g. use "gh release list --json
tagName" to output tag names, pipe through jq to extract tagName, then sort them
by version (sort -V or a semver-aware tool) and pick the last entry). Update the
LATEST variable assignment (the line setting LATEST) to use that pipeline so
LATEST always holds the highest semantic version tag rather than the most
recent-by-date release.
- Around line 69-73: The normalize() helper in auto-release.yml currently
replaces pre-release suffixes like -beta(.N) / -alpha(.N) / -rc(.N) with
b0/a0/rc0, dropping the numeric counter and making Version() treat different
prereleases as equal; update normalize() to preserve the numeric counter (e.g.,
replace -beta(.N)? with bN, -alpha(.N)? with aN, -rc(.N)? with rcN by capturing
the digits and inserting them into the replacement) or remove normalize()
entirely and rely on packaging.version.Version() to parse prerelease suffixes;
look for the normalize function definition to implement the change.
- Around line 31-37: The workflow uses Python 3.10 but the step "Get version
from pyproject.toml" (id: pyproject_version) calls python -c "import tomllib;
...", which will fail because tomllib is available only in Python 3.11+; either
bump the job's python-version to "3.11" (or higher) or change the pyproject
parsing command to use the backport (tomli) under the configured interpreter
(install tomli in the step and replace import tomllib with import tomli) so the
VERSION extraction and echo "version=$VERSION" >> $GITHUB_OUTPUT succeed
reliably.
- Around line 39-49: The workflow currently interpolates
steps.pyproject_version.outputs.version directly into shell and Python string
literals (seen in the tag_check step and the version_check / gh release create
steps), which allows injection; instead export the version into the step's env
(e.g., VERSION=${{ steps.pyproject_version.outputs.version }}) and reference
that runtime env variable in commands—use "gh release view \"$VERSION\"" (or
better, avoid embedding in a Python -c string) and change the python -c usage in
version_check to read os.environ['VERSION'] (or os.getenv) rather than embedding
'${{ ... }}'; apply the same env-passing approach to the gh release create step
so no untrusted content is interpolated into shell/Python literals.
---
Nitpick comments:
In @.github/workflows/auto-release.yml:
- Around line 28-31: The "Install uv" step using
astral-sh/setup-uv@d4b2f3b6ecc6e67c4457f6d3e41ec42d3d0fcb86 currently enables
caching by default; disable caching for this privileged release job by adding
the cache parameter to the step (e.g., add under the with: block for the
"Install uv" step — python-version: "3.10" — a cache: false entry) so the action
runs without using or writing a cached UV installation.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: af1979a0-a606-4814-82ef-bee0c4a2adac
📒 Files selected for processing (2)
.github/workflows/auto-release.yml.github/workflows/release_to_pypi.yml
💤 Files with no reviewable changes (1)
- .github/workflows/release_to_pypi.yml
tomllib is stdlib only from 3.11+; the job uses 3.10. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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
.github/workflows/auto-release.yml— a self-contained release workflow that runs on every push tomain.github/workflows/release_to_pypi.yml(now redundant)minerva/__init__.pyto useimportlib.metadatasopyproject.tomlis the single source of truth for the versionHow it works
versionfrompyproject.tomland compares it against the latest GitHub Release tag usingpackaging.version. Exits early if the version has not changed or the tag already exists (idempotent).uv buildgh release createwith auto-generated notes and the built dist artifacts attached.pypa/gh-action-pypi-publish.A
concurrency: group: releaselock prevents race conditions if two pushes land in quick succession.To release a new version going forward: bump
versioninpyproject.toml, push/merge tomain— everything else is automatic.Notes
minerva/__init__.pynow reads__version__dynamically from the installed package metadata viaimportlib.metadata. No version string ever needs to be manually updated outside ofpyproject.toml.release_to_pypi.ymlis removed becauseauto-release.ymlcovers the full release flow. Releases created viaGITHUB_TOKENdo not re-trigger other workflows, so there is no risk of double-publishing.pypiGitHub environment and its OIDC trust configuration remain unchanged.🤖 Generated with Claude Code