chore(ci): document main branch protection at release boundary (#108)#123
Conversation
Mirrors `dev`'s four required status checks onto `main` (Lint & Format, Type Check, Test, Migration Check; strict=true). Documents the new protection in three places so future contributors and the release-trigger runbook stay accurate: - `docs/_base/PIPELINE_CONTRACT.md` — Merge Conditions table now shows the four `main` gates explicitly; verification-date refreshed to 2026-05-14; enforce_admins note expanded to call out that the empty-`feat:` trigger PR must now wait for the same four checks before admin-merge. - `docs/GIT-GITHUB-GUIDE.md` — branch summary + release-flow step 2 reflect the enforced gates. - `docs/_base/RUNBOOKS.md` — release-please recovery procedure step 4 now spells out the new wait-for-CI requirement explicitly. `enforce_admins: false` preserved per #108 out-of-scope, so the release-trigger admin-merge workaround still works (it just has to wait for CI like every other PR to `main`). The protection itself is applied out-of-band via `gh api -X PUT repos/w7-mgfcode/ForecastLabAI/branches/main/protection` because branch-protection writes are not reviewable in a PR diff; this commit documents the post-write state. Closes #108.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 |
Reviewer's guide (collapsed on small PRs)Reviewer's GuideDocuments that the main branch now enforces the same four CI status checks as dev (Lint & Format, Type Check, Test, Migration Check, strict=true) at the branch-protection layer, and updates release/runbook docs so reviewers understand how this affects dev→main releases and the empty-feat release trigger workflow. Flow diagram for dev→main release boundary with mirrored CI gatesflowchart LR
dev[dev branch]
main[main branch]
pr[PR dev → main]
checks[[4 CI checks<br/>Lint & Format<br/>Type Check<br/>Test<br/>Migration Check]]
protection{{main branch protection<br/>required_status_checks.strict = true}}
merge[(Merge allowed)]
release[release-please<br/>release workflow]
dev --> pr
pr --> checks
checks --> protection
protection -->|all 4 green| merge
merge --> main
main --> release
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The list of four required CI checks is duplicated verbatim across multiple docs (GIT-GITHUB-GUIDE, PIPELINE_CONTRACT, RUNBOOKS), which risks drift the next time a gate is added/renamed; consider centralizing this description in a single canonical section and linking to it from other docs.
- Long-lived docs now reference specific issue/PR numbers (e.g., #108, #99–#101) inline; you might want to either link them explicitly or move these historical references to a short "background" note so that the primary flow stays focused on the current behavior.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The list of four required CI checks is duplicated verbatim across multiple docs (GIT-GITHUB-GUIDE, PIPELINE_CONTRACT, RUNBOOKS), which risks drift the next time a gate is added/renamed; consider centralizing this description in a single canonical section and linking to it from other docs.
- Long-lived docs now reference specific issue/PR numbers (e.g., #108, #99–#101) inline; you might want to either link them explicitly or move these historical references to a short "background" note so that the primary flow stays focused on the current behavior.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Summary
Closes #108. Mirrors
dev's four required CI checks (Lint & Format,Type Check,Test,Migration Check,strict: true) ontomainand documents the new protection. This closes the gap wheremainhadrequired_status_checks: nullat the branch-protection layer — the release boundary now refuses adev → mainmerge with broken CI.What's in the diff
Docs-only (3 files, 7 lines net). The protection-config write itself is applied out-of-band via
gh api -X PUT repos/w7-mgfcode/ForecastLabAI/branches/main/protectionbecause branch-protection writes don't render in a PR diff. This PR documents the post-write state so the diff stays reviewable.docs/_base/PIPELINE_CONTRACT.md— Merge Conditions table:mainrow now lists the same four gates asdev; verification date refreshed to 2026-05-14.enforce_admins: falsenote expanded to call out that the empty-feat:release-trigger PR must now wait for the same four checks before admin-merge.docs/GIT-GITHUB-GUIDE.md— branch-summary table + §4.2 step 2 reflect the enforced gates.docs/_base/RUNBOOKS.md— release-please recovery step 4 now spells out the wait-for-CI requirement explicitly.Out of scope (per #108)
enforce_adminsstaysfalse— preserves the documented empty-feat:release-trigger workaround (it now just has to wait for CI like every other PR tomain).required_approving_review_count: 1.Verification commands
After the protection write lands:
Expected:
required_status_checks.contextslists the four jobs;required_status_checks.strict: true;enforce_admins.enabled: false.Test plan
uv run ruff check .+uv run ruff format --check .— clean (docs-only diff, no code touched)mypy --strict/pyright --strict/pytestpaths unaffectedgh api .../main/protectionreflects the four gates after the operational PUTAfter merge
The next
dev → mainPR will be the first one to exercise the new gates — that's also the merge the maintainer wants to cut the next release.Summary by Sourcery
Document alignment of main branch protection with dev by mirroring four required CI status checks at the release boundary and updating release flow docs accordingly.
Documentation: