Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 25 minutes and 32 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, 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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #262 +/- ##
=======================================
Coverage 69.84% 69.84%
=======================================
Files 140 140
Lines 10743 10743
=======================================
Hits 7503 7503
Misses 3240 3240 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
Adds release automation via release-please for the Python SDK repo, including configuration, manifest, a GitHub Actions workflow, and operator documentation.
Changes:
- Add
release-please-config.jsonand.release-please-manifest.jsonto drive automated versioning and changelog generation. - Add a
release-pleaseGitHub Actions workflow withworkflow_dispatchinputs. - Add
RELEASE.mdand annotateSDK_VERSIONfor release-please-managed updates.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
RELEASE.md |
New release runbook describing how to cut releases and troubleshoot release-please. |
release-please-config.json |
Release-please configuration for Python releases, changelog sections, and extra files to bump. |
openfga_sdk/constants.py |
Marks SDK_VERSION for automated version bumping. |
.release-please-manifest.json |
Initializes the release-please manifest version. |
.github/workflows/release-please.yml |
Adds the workflow that runs the reusable release-please automation. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| SDK_VERSION: Final[str] = "0.10.0" # x-release-please-version | ||
|
|
||
| # User agent used in HTTP requests. | ||
| USER_AGENT: Final[str] = "openfga-sdk python/0.10.0" |
There was a problem hiding this comment.
USER_AGENT hardcodes the version string (0.10.0). When release-please bumps SDK_VERSION, USER_AGENT will drift and will likely break test/constants_consistency_test.py (it asserts SDK_VERSION in USER_AGENT). Consider deriving USER_AGENT from SDK_VERSION (e.g. via f-string) or add an x-release-please-version marker so both get updated together.
| USER_AGENT: Final[str] = "openfga-sdk python/0.10.0" | |
| USER_AGENT: Final[str] = f"openfga-sdk python/{SDK_VERSION}" |
| bump-type: ${{ inputs.bump-type || 'auto' }} | ||
| release-version: ${{ inputs.release-version || '' }} |
There was a problem hiding this comment.
The workflow is triggered on both push and workflow_dispatch, but the with: block references inputs.*. The inputs context only exists for workflow_dispatch/workflow_call, and the input names also contain hyphens (which require bracket notation). This will fail on push runs and may also fail to parse for the hyphenated keys. Use github.event.inputs['bump-type'] / github.event.inputs['release-version'] (with sensible defaults) or gate access based on github.event_name.
| bump-type: ${{ inputs.bump-type || 'auto' }} | |
| release-version: ${{ inputs.release-version || '' }} | |
| bump-type: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs['bump-type'] || 'auto' }} | |
| release-version: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs['release-version'] || '' }} |
|
|
||
| jobs: | ||
| release: | ||
| uses: openfga/sdk-generator/.github/workflows/release-please.yml@main |
There was a problem hiding this comment.
The reusable workflow is referenced by branch (openfga/sdk-generator/...@main). For release automation, pinning to an immutable ref (tag or commit SHA) helps avoid supply-chain risk and unexpected behavior changes when main moves.
| uses: openfga/sdk-generator/.github/workflows/release-please.yml@main | |
| uses: openfga/sdk-generator/.github/workflows/release-please.yml@3c5c1b9c8d4e2f6a7b8c9d0e1f2a3b4c5d6e7f8 |
| This project uses [release-please](https://github.com/googleapis/release-please) via a | ||
| `workflow_dispatch`-triggered GitHub Actions workflow. This document explains how to cut | ||
| a release and what to watch out for. |
There was a problem hiding this comment.
The guide says releases use a workflow_dispatch-triggered workflow, but .github/workflows/release-please.yml is also configured to run on push to main. Please update the wording to reflect the actual triggers so operators aren’t surprised by automatic runs.
| - `patch` — bugfixes, docs, small changes | ||
| - `minor` — breaking changes (see above) | ||
| - `explicit` — you specify the exact version string (e.g. `0.11.0` or `0.11.0-beta.1`) |
There was a problem hiding this comment.
The bump-type list omits auto and major, but the workflow dropdown includes both, and later text references patch/minor/major convenience options. Update the step to document all available choices and when to use them to avoid operator error.
| - `patch` — bugfixes, docs, small changes | |
| - `minor` — breaking changes (see above) | |
| - `explicit` — you specify the exact version string (e.g. `0.11.0` or `0.11.0-beta.1`) | |
| - `auto` — let release-please infer the next version from Conventional Commit types; | |
| use this only when the previous tag was a normal release (no pre-release suffix) | |
| and there are no manually created tags since then. | |
| - `patch` — convenience option for a patch bump (`0.0.x`): bugfixes, docs, small | |
| changes that are not intentionally breaking. | |
| - `minor` — convenience option for a minor bump (`0.x.0`): use for breaking changes | |
| under the pre-1.0.0 rules described above. | |
| - `major` — convenience option for a major bump (`1.0.0`, `2.0.0`, …); in this | |
| project, use only for a deliberate stable-API graduation decision, not for routine | |
| breaking changes. | |
| - `explicit` — you specify the exact version string (e.g. `0.11.0` or | |
| `0.11.0-beta.1`); recommended when in doubt, and in all the situations listed in | |
| the **When to use `explicit`** section below. |
| fix: correct retry logic for transient errors → Fixed | ||
| docs: update API reference → Documentation | ||
| perf: cache DNS lookups → Changed | ||
| refactor: extract auth helper → (hidden) |
There was a problem hiding this comment.
The Conventional Commits → changelog mapping example marks refactor as “(hidden)”, but release-please-config.json configures refactor as visible (hidden: false) under the “Changed” section. Align the example with the config (or adjust the config) so the generated changelog matches the documented expectations.
| refactor: extract auth helper → (hidden) | |
| refactor: extract auth helper → Changed |
Description
What problem is being solved?
How is it being solved?
What changes are made to solve it?
References
Review Checklist
main