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 27 minutes and 1 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 |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| uses: openfga/sdk-generator/.github/workflows/release-please.yml@main | ||
| with: | ||
| bump-type: ${{ inputs.bump-type || 'auto' }} | ||
| release-version: ${{ inputs.release-version || '' }} | ||
| secrets: | ||
| APP_ID: ${{ secrets.APP_ID }} | ||
| APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }} |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 4 days ago
In general, fix this by adding an explicit permissions: block that grants only the scopes needed for the workflow to operate, either at the workflow root (applies to all jobs) or under the specific job. Because this workflow solely delegates to a reusable workflow that likely performs release operations (tagging, creating GitHub releases, etc.), we should start from a safe minimal set and then allow contents write access so releases and tags can be created while keeping other scopes at their default (none).
The best minimally invasive fix is to add a permissions: block at the top level, just after the on: trigger, to constrain the GITHUB_TOKEN for all jobs in this workflow (there is only one job, release). A conservative configuration for a release workflow is:
permissions:
contents: writeThis assumes the reusable workflow needs to create/update releases or tags (which is standard for release-please). If the project later finds this is too strong, they can refine it further, but this is the smallest reasonable change that addresses the CodeQL warning and maintains expected behavior. Concretely, edit .github/workflows/release-please.yml to insert the permissions: block between the on: section (ending at line 26–27) and the jobs: section (line 28). No additional imports or dependencies are required.
| @@ -25,6 +25,9 @@ | ||
| required: false | ||
| type: string | ||
|
|
||
| permissions: | ||
| contents: write | ||
|
|
||
| jobs: | ||
| release: | ||
| uses: openfga/sdk-generator/.github/workflows/release-please.yml@main |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #362 +/- ##
=======================================
Coverage 85.80% 85.80%
=======================================
Files 26 26
Lines 1268 1268
Branches 225 249 +24
=======================================
Hits 1088 1088
Misses 110 110
Partials 70 70 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
SoulPancake
changed the title
There was a problem hiding this comment.
Pull request overview
Adds release automation and documentation for managing version bumps and changelogs using release-please.
Changes:
- Introduces release-please configuration and manifest for automated versioning/changelog generation.
- Adds a reusable GitHub Actions workflow entrypoint for running release-please.
- Documents the release process and versioning rules in a new
RELEASE.md.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
RELEASE.md |
Adds a release guide describing the intended release workflow and conventions. |
release-please-config.json |
Configures release-please behavior (changelog sections, pre-1.0 bump rules, extra file updates). |
constants/index.ts |
Adds a release-please version marker to keep SdkVersion updated automatically. |
.release-please-manifest.json |
Seeds release-please manifest with the current version. |
.github/workflows/release-please.yml |
Adds a workflow to run the shared release-please reusable workflow. |
Comments suppressed due to low confidence (1)
constants/index.ts:22
- Release-please will update
SdkVersionvia thex-release-please-versionmarker, butUserAgentstill embeds a hard-coded version string. On the next release, these can drift and produce incorrect user-agent strings/telemetry. Consider derivingUserAgentfromSdkVersion(or adding a release-please marker/update pattern forUserAgentas well).
const SdkVersion = "0.9.4"; // x-release-please-version
/**
* User agent used in HTTP requests.
*/
const UserAgent = "openfga-sdk js/0.9.4";
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -0,0 +1,3 @@ | |||
| { | |||
| ".": "0.9.3" | |||
There was a problem hiding this comment.
.release-please-manifest.json is set to 0.9.3, but the repo’s current version appears to be 0.9.4 (e.g., package.json and CHANGELOG.md reference v0.9.4). This mismatch can cause release-please to compute the next version incorrectly or generate a no-op/incorrect release PR. Align the manifest version with the current released version/tag.
| ".": "0.9.3" | |
| ".": "0.9.4" |
| 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.
This guide states releases use a workflow_dispatch-triggered workflow, but .github/workflows/release-please.yml is also configured to run on push to main. Please align the documentation with the actual workflow triggers (or remove the push trigger if manual dispatch is intended).
| 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 examples indicate refactor: commits are hidden from the changelog, but release-please-config.json configures refactor with hidden: false (it will be published under “Changed”). Please align the guide with the config (either update this section or set the refactor section to hidden).
| 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