ci: integrate release-please action#116
Conversation
Adopt release-please for automated versioning and releases, modeled on the hub-seeder setup and adapted for Python/Poetry/PyPI. - Add release-please-config.json (release-type: python, v-prefixed tags, bump-minor-pre-major) and bootstrap .release-please-manifest.json to the current version 0.2.16 to align with existing v* tags. - Add release.yml that runs release-please on pushes to main and, once a release is created, builds the package, publishes to PyPI via trusted publishing, and deploys the Sphinx docs. - Remove publish.yml and sphinx.yml; their tag-triggered jobs are folded into release.yml since tags created with GITHUB_TOKEN do not trigger separate workflows.
|
Warning Review limit reached
Next review available in: 55 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughRemoves separate ChangesRelease CI/CD consolidation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/release.yml:
- Around line 11-14: The workflow-level permissions are too broad and currently
grant write access to every job, including ones that do not need it. Update the
release workflow so the existing permissions are scoped per job instead of at
the top level: keep write access only on the release-please and docs jobs, and
leave build and publish with read-only or no permissions. Use the job names and
the workflow permissions block in release.yml to locate and move the settings.
🪄 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: 77bed367-2030-4679-9cb8-dc2723a6bfa7
📒 Files selected for processing (5)
.github/workflows/publish.yml.github/workflows/release.yml.github/workflows/sphinx.yml.release-please-manifest.jsonrelease-please-config.json
💤 Files with no reviewable changes (2)
- .github/workflows/sphinx.yml
- .github/workflows/publish.yml
| permissions: | ||
| contents: write | ||
| pull-requests: write | ||
|
|
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Scope workflow permissions per job.
contents: write and pull-requests: write are currently granted to every job, including build and publish, which do not need them. That unnecessarily widens the blast radius for third-party actions and shell steps; move these permissions onto release-please and docs, and leave the other jobs read-only or tokenless.
Suggested tightening
-permissions:
- contents: write
- pull-requests: write
-
jobs:
release-please:
runs-on: ubuntu-latest
+ permissions:
+ contents: write
+ pull-requests: write
outputs:
releases_created: ${{ steps.release.outputs.releases_created }}
@@
build:
runs-on: ubuntu-latest
needs: release-please
if: needs.release-please.outputs.releases_created == 'true'
+ permissions:
+ contents: read
@@
publish:
runs-on: ubuntu-latest
needs: build
environment: pypi
permissions:
id-token: write
@@
docs:
runs-on: ubuntu-latest
needs: release-please
if: needs.release-please.outputs.releases_created == 'true'
permissions:
contents: write📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| permissions: | |
| contents: write | |
| pull-requests: write |
🧰 Tools
🪛 zizmor (1.26.1)
[error] 12-12: overly broad permissions (excessive-permissions): contents: write is overly broad at the workflow level
(excessive-permissions)
[error] 13-13: overly broad permissions (excessive-permissions): pull-requests: write is overly broad at the workflow level
(excessive-permissions)
🤖 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/release.yml around lines 11 - 14, The workflow-level
permissions are too broad and currently grant write access to every job,
including ones that do not need it. Update the release workflow so the existing
permissions are scoped per job instead of at the top level: keep write access
only on the release-please and docs jobs, and leave build and publish with
read-only or no permissions. Use the job names and the workflow permissions
block in release.yml to locate and move the settings.
Source: Linters/SAST tools
1 participant
Integrate release-please for automated versioning and releases, modeled on the hub-seeder setup and adapted for this Python/Poetry/PyPI project.
Changes
release-please-config.json—release-type: python(bumpsversioninpyproject.toml),include-v-in-tag: true(matches existingv*tags),bump-minor-pre-major: true(pre-1.0:feat:→ minor,fix:→ patch)..release-please-manifest.json— bootstrapped to the current version0.2.16so release-please continues cleanly from the existingv0.2.16tag instead of starting a new series..github/workflows/release.yml— runs on push tomain; therelease-pleasejob maintains the release PR, and once a release is created it builds the package, publishes to PyPI (trusted publishing / OIDC), and deploys the Sphinx docs to GitHub Pages.publish.ymlandsphinx.yml— their tag-triggered jobs are folded intorelease.yml. Tags created by release-please useGITHUB_TOKEN, which by design does not trigger separate tag-triggered workflows, so the standalone files would never have fired.Follow-up required before this works
pypienvironment must remain in place (reused unchanged from the oldpublish.yml).Behavior note
With
bump-minor-pre-major,feat:commits now produce minor bumps (e.g.0.3.0) rather than the manual patch bumps used previously. This is standard release-please/semver behavior and matches hub-seeder.Summary by CodeRabbit
New Features
Chores