Introduce release-docs publishing workflow#91
Conversation
- Run the existing lint and test workflows for pushes and pull requests targeting release-docs - Keep the public-docs branch under the same baseline validation as main before Mintlify publishes from it
- Add a dedicated workflow that runs whenever release-docs receives new commits - Reuse one sync PR so released-doc fixes are surfaced in main without relying on manual follow-up
- Explain when docs changes belong on release-docs versus main in the contributing guide - Add PR template checks so branch targeting is explicit during review
- Record the Mintlify branch switch, workflow permissions, and branch protection rules in one runbook - Give the team a repeatable process for public-doc hotfixes and release promotions
- Stop tracking local runbooks and execution logs that should stay ephemeral during workflow setup - Keep the branch focused on repo changes while leaving these files available locally
- Restore the existing tracked execution log so this workflow PR\n does not remove it prematurely\n- Leave cleanup of legacy tracked logs to a separate follow-up\n as planned
|
Warning Review limit reached
Next review available in: 37 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. 📝 Walkthrough
✨ 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 |
- Replace the branch-targeting shorthand with a dedicated docs contribution section in the contributing guide - Explain the main versus release-docs workflow in PR language that matches how engineers usually decide where a docs change should go
1 participant
Why
This PR implements the
release-docsworkflow so we can actively document changes in the main branch while stable docs stay onrelease-docs. It ensures that when hotfixes are made on release-docs, a PR is automtically opened to update docs in the main branch.What this PR covers
release-docsrelease-docs -> mainsync PRBehavior Impact
release-docs, and pushes torelease-docscan create sync PRs once repository workflow permissions are enabled