Use Client ID for dashboard GitHub App config - #394
Conversation
|
Warning Review limit reached
Next review available in: 34 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 Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (33)
✨ 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 |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_bd40023b-7bad-4e24-b796-68e69d90df96) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7f6f67afcf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| payload = self._request( | ||
| "GET", | ||
| "/search/issues", | ||
| params={"q": " ".join(search_terms), "per_page": min(max(limit, 1), 20)}, | ||
| f"/orgs/{organization}/projectsV2", | ||
| params={"per_page": min(max(limit, 1), 100)}, | ||
| permissions={"organization_projects": "read"}, |
There was a problem hiding this comment.
GitHub Projects v2 is exposed through GraphQL, not REST routes such as /orgs/{organization}/projectsV2, so a Steering Committee request such as “List GitHub Projects” receives a 404; the get, fields, items, add, and update methods below use the same nonexistent route family and numeric IDs, leaving the entire newly advertised Projects workflow unusable. Implement these operations with the Projects v2 GraphQL queries and mutations and their node IDs instead.
Useful? React with 👍 / 👎.
| f"/repos/{repository}/issues", | ||
| params={ | ||
| "state": _issue_state(state), | ||
| "per_page": min(max(bounded_limit * 5, 30), 100), | ||
| "sort": "updated", |
There was a problem hiding this comment.
When a repository has more than 30–100 issues and the requested match is not among the most recently updated first page, this fetches one bounded page and filters it locally, causing github_issue.search_issues to report no match even though the issue exists. The previous Search API queried the whole repository; either retain that behavior or paginate issue pages until the requested result limit is satisfied or the collection is exhausted.
Useful? React with 👍 / 👎.
| if ( | ||
| not self.github_app_configured | ||
| and normalized_repository in self.github_configured_repositories | ||
| ): | ||
| return f"github:repository:configured:{suffix}" |
There was a problem hiding this comment.
When a deployment is still using the documented GITHUB_API_TOKEN/GITHUB_ALLOWED_REPOS compatibility path, an Admin, Owner, or Steering Committee user targeting a nondefault allowed repository is assigned github:repository:configured:{read,write} here, but the admin role only has the all and legacy issue scopes; authorization therefore denies the request before _resolve_repository can apply the allowlist. Add the configured repository scopes to the admin role or classify privileged legacy requests under a scope admins possess.
Useful? React with 👍 / 👎.
| if state is not None: | ||
| payload["state"] = _issue_state(state) |
There was a problem hiding this comment.
all state for issue updates
When the structured planner proposes an issue update with state: "all", the action passes the planner shape checks and reaches this shared _issue_state validator, which accepts all for issue listings; the subsequent PATCH is invalid because GitHub issue updates only accept open or closed, so a user can confirm a write that inevitably fails. Validate update states separately from list states before creating the confirmation plan.
Useful? React with 👍 / 👎.
| if tool_name == "github_repository.list_repositories": | ||
| _require_any_scope( | ||
| github_scopes, | ||
| {"github:repository:all:read", "github:repository:all:write"}, | ||
| message="Listing GitHub repositories requires Steering Committee access", | ||
| ) | ||
| return self._github_client().list_installation_repositories() |
There was a problem hiding this comment.
When the documented legacy GITHUB_API_TOKEN fallback is active and a Steering Committee/Admin user asks to list repositories, _github_client() constructs a static PAT-backed client but this branch unconditionally calls /installation/repositories, which requires a GitHub App installation access token; the newly exposed command therefore fails instead of returning the configured legacy allowlist or explaining that App credentials are required. Gate this tool on a complete App configuration or provide a PAT-compatible legacy implementation.
Useful? React with 👍 / 👎.
1 participant
Summary
GITHUB_APP_IDas a legacy environment alias and refresh the checked-in dashboard bundleValidation
uv run --group dev pytest -q tests/ --tb=short— 1936 passed, 21 skippedNote
Medium Risk
Changes touch GitHub App authentication and secret handling in the admin dashboard; misconfiguration could break Discord/agent GitHub tools until credentials are corrected.
Overview
GitHub App auth now treats the App Client ID as the installation-token JWT issuer, with
GITHUB_APP_IDkept only as an env alias forGITHUB_APP_CLIENT_ID.Dashboard → Configuration → Operations exposes Client ID, installation ID, and an encrypted multiline PEM private key (new
multilinefield type with a textarea);GITHUB_APP_*settings surface in the primary table..env.example, README, anddocs/discord-github-todos.mddocument the todos backend, repo access model, and App vs legacy token setup.The checked-in dashboard static bundle is refreshed to ship the UI changes.
Reviewed by Cursor Bugbot for commit 7f6f67a. Bugbot is set up for automated code reviews on this repo. Configure here.