ci: allow required checks to run on bot-authored PRs - #56
Conversation
Both required status checks (`validate`, `build-site`) only triggered on `pull_request`. GitHub deliberately does not fire `pull_request` for PRs opened with the default GITHUB_TOKEN, to avoid recursive workflow runs. release-please opens its release PR with GITHUB_TOKEN, so neither required check ever reported on it. With `enforce_admins: true` and both contexts required, that left the release PR permanently BLOCKED with zero check runs — unmergeable by any means short of weakening branch protection. Adds `workflow_dispatch` to validate-packages.yml (ci.yml already had it) so both required contexts can be run against such a branch and report status. Comments on both triggers record why they must stay. The alternative — giving release-please a PAT — needs an interactively created secret and trades a deadlock for a long-lived credential; this keeps branch protection intact and adds no secret.
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
Warning Review limit reached
Next review available in: 45 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 selected for processing (2)
✨ 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 |
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Summary
This PR successfully addresses the structural issue preventing required status checks from reporting on bot-authored PRs. The changes are clean and well-documented:
- Adds
workflow_dispatchtrigger tovalidate-packages.ymlto enable manual workflow runs - Documents the rationale with clear inline comments in both workflow files
- Maintains all existing functionality while solving the unmergeable PR problem
The implementation is correct and ready to merge. No defects or blocking issues identified.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
Follow-up to #56, which added workflow_dispatch to the required workflows so a release-please PR could be unblocked. That made the checks *runnable* but not automatic — someone still had to trigger them by hand, so a fresh release PR (#59) came back with zero check runs and sat BLOCKED exactly as before. A manual escape hatch is not a fix. The Release job now dispatches `ci.yml` and `validate-packages.yml` against the release branch immediately after release-please creates or updates its PR, so the required contexts report without human intervention. Gated on `prs_created` and parsing the branch from the action's `pr` output with jq at runtime, so the step is skipped entirely on release-only runs and fails loudly rather than silently dispatching a wrong ref. Needs `actions: write` to dispatch, which is added narrowly to this workflow.
1 participant
Problem
Both required status checks (
validate,build-site) triggered only onpull_request. GitHub deliberately does not firepull_requestfor PRs opened with the defaultGITHUB_TOKEN, to prevent recursive workflow runs.release-please opens its release PR with
GITHUB_TOKEN, so neither required check ever reported on it:With
enforce_admins: trueand both contexts required, PR #2 has been permanently unmergeable since it was opened — not by any transient CI failure, but structurally.Fix
Adds
workflow_dispatchtovalidate-packages.yml(ci.ymlalready had it), so both required contexts can be run against such a branch and report status. Both triggers now carry a comment recording why they must stay.Alternative considered
Giving release-please a PAT via
token:would also work, but requires an interactively created secret and trades a deadlock for a long-lived credential. This approach keeps branch protection fully intact (enforce_adminsstays on) and introduces no new secret.Verification
Both workflows parsed and triggers confirmed: