docs: add development workflow playbook (fix/feature/release)#81
Conversation
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Reviewer's GuideAdds a new documentation playbook describing the end-to-end development workflow for fixes, features, and releases, and wires it into existing contributor and docs indexes so maintainers and contributors have a single “how we ship” reference without changing any code paths. Flow diagram for the label-driven release workflowflowchart TD
Developer([Developer])
bump_version_py[bump_version.py]
check_release_metadata_py[check_release_metadata.py]
ReleaseDrafter[ReleaseDrafter]
GitHubReleaseDraft[GitHub Release draft]
publish_pypi_yml[publish-pypi.yml]
PyPI[PyPI easycord project]
Developer -->|merge PRs with labels| ReleaseDrafter
Developer -->|run bump_version.py 5.X.Y| bump_version_py
bump_version_py -->|self validate| check_release_metadata_py
Developer -->|push release branch and open PR| GitHubReleaseDraft
ReleaseDrafter -->|maintain draft from labels| GitHubReleaseDraft
Developer -->|publish drafted release| publish_pypi_yml
publish_pypi_yml -->|build wheel and sdist, upload| PyPI
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Review limit reached
Next review available in: 56 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: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ 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 |
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The hard-coded
>=20 tests per pluginthreshold in the local gate and feature sections is likely to drift from CI rules over time; consider centralizing this limit (e.g., in one doc or config) and referencing it instead of repeating a specific number. - The invariants section duplicates content from
CONTRIBUTING.md#key-invariants-easy-to-get-wrong; to avoid future divergence, consider either linking directly to that section only or clearly indicating this is a curated subset that doesn’t need to stay in strict sync.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The hard-coded `>=20 tests per plugin` threshold in the local gate and feature sections is likely to drift from CI rules over time; consider centralizing this limit (e.g., in one doc or config) and referencing it instead of repeating a specific number.
- The invariants section duplicates content from `CONTRIBUTING.md#key-invariants-easy-to-get-wrong`; to avoid future divergence, consider either linking directly to that section only or clearly indicating this is a curated subset that doesn’t need to stay in strict sync.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
What changed
Adds
docs/development-workflow.md— the end-to-end "how we ship" guide for maintainers and contributors, covering the three workflows the repo's machinery already implies:Also links the new guide from
CONTRIBUTING.md(one-line pointer) and both tables indocs/README.md.Why
CONTRIBUTING.md covers standards and conventions but no doc tied together the full lifecycle from branch to PyPI; the release steps and label→version mapping lived only in workflow YAML and scripts.
Test plan
python scripts/check_release_metadata.pypasses (no version drift introduced)Summary by Sourcery
Add a maintainer-focused development workflow playbook describing how to refine/fix behavior, add features, and perform releases, and link it from contributor and docs indexes.
Documentation: