Repository navigation
chore(ci): document/add Frontend build (PR) as required status check (closes #377) - #849
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 13 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)
📝 WalkthroughWalkthroughA new runbook is added to ChangesCI Required Checks Runbook
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
|
@coderabbitai review |
Rate Limit Exceeded
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai full review |
✅ Action performedFull review finished. |
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
Both branches are currently unprotected (HTTP 404 on the protection API), so the required-check cannot be added programmatically without repo-admin rights. Add docs/ci-required-checks.md with the exact gh api commands an admin must run to create the protection rule and add "Frontend build (PR)" to required checks on feat/multicloud-web-frontend and main.
… (refs #377) GitHub branch-protection contexts use the job name:, not the workflow name:. The workflow is named 'Frontend build (PR)' but its single job is 'Build frontend', so the context an admin must register is 'Build frontend'. The doc had the wrong string throughout; an admin following it verbatim would add a non-existent context and branch protection would never block a failing frontend build. Also adds a note in the Context section explaining the workflow-name vs job-name distinction so future maintainers understand the correct string to use.
The frontend-build.yml trigger for feat/multicloud-web-frontend was removed when that branch merged into main (commit 4f7d429). The Build frontend check therefore only fires on main-targeting PRs, so branch protection instructions for the retired branch are misleading. Removes the feat/multicloud-web-frontend commands from all four admin steps and the required-checks list; updates the Context section to explain why main is the only active target.
Summary
docs/ci-required-checks.mddocumenting the canonical required statuschecks for
feat/multicloud-web-frontendandmain, including step-by-stepadmin commands (closes chore(ci): add 'Frontend build (PR)' to required status checks on feat/multicloud-web-frontend + main #377).
Frontend build (PR)as a required check was attemptedbut both branches currently have no protection rule (HTTP 404). Because
creating protection rules from scratch requires repo-admin permissions, the
runbook documents the exact
gh api -X PUTcommand an admin must run.Admin action required
Neither
feat/multicloud-web-frontendnormainhas a branch protectionrule yet. A repo-admin must follow
docs/ci-required-checks.mdStep 3 tocreate protection and add
Frontend build (PR)to required checks.Test plan
docs/ci-required-checks.mdFrontend build (PR)frontend/andconfirms merge is blocked until the check turns green
Summary by CodeRabbit
Release Notes