Skip to content

chore(ci): document main branch protection at release boundary (#108)#123

Merged
w7-mgfcode merged 1 commit into
devfrom
chore/ci-tighten-main-branch-protection
May 14, 2026
Merged

chore(ci): document main branch protection at release boundary (#108)#123
w7-mgfcode merged 1 commit into
devfrom
chore/ci-tighten-main-branch-protection

Conversation

@w7-mgfcode
Copy link
Copy Markdown
Owner

@w7-mgfcode w7-mgfcode commented May 14, 2026

Summary

Closes #108. Mirrors dev's four required CI checks (Lint & Format, Type Check, Test, Migration Check, strict: true) onto main and documents the new protection. This closes the gap where main had required_status_checks: null at the branch-protection layer — the release boundary now refuses a dev → main merge 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/protection because 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: main row now lists the same four gates as dev; verification date refreshed to 2026-05-14. enforce_admins: false note 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_admins stays false — preserves the documented empty-feat: release-trigger workaround (it now just has to wait for CI like every other PR to main).
  • No code owners added.
  • No additional review requirements beyond the existing required_approving_review_count: 1.

Verification commands

After the protection write lands:

gh api repos/w7-mgfcode/ForecastLabAI/branches/main/protection | python3 -m json.tool | head -30

Expected: required_status_checks.contexts lists 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)
  • No code changes; mypy --strict / pyright --strict / pytest paths unaffected
  • CI gates green on this PR (Lint & Format, Type Check, Test, Migration Check)
  • Follow-up: confirm gh api .../main/protection reflects the four gates after the operational PUT

After merge

The next dev → main PR 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:

  • Update Git/GitHub guide to describe the four enforced CI gates on dev and main and their effect on the dev → main release flow.
  • Refresh pipeline contract to record main’s required status checks, strict mode, and admin-merge behavior after adding the four CI gates.
  • Clarify runbook instructions for release-please recovery to require waiting for the four main CI checks before performing the admin merge.

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.
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 14, 2026

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: b22cff65-f072-4fdc-ae90-7a95086a1ce5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/ci-tighten-main-branch-protection

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@sourcery-ai
Copy link
Copy Markdown

sourcery-ai Bot commented May 14, 2026

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Documents 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 gates

flowchart 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
Loading

File-Level Changes

Change Details Files
Align and document main-branch CI protection with dev by updating the merge-conditions contract.
  • Update verification date for branch protection configuration for dev and main
  • Change main’s merge conditions from having no required status checks to mirroring dev’s four CI gates with strict status checks
  • Record that main now has dismiss_stale_reviews: false while retaining other protection flags
  • Clarify enforce_admins: false behavior now that main has required status checks, including required wait for four CI jobs on empty-feat release-trigger PRs
docs/_base/PIPELINE_CONTRACT.md
Document the enforced CI gates for dev and main in the Git/GitHub workflow guide, including the release flow.
  • Expand dev branch description to list the four CI gates explicitly in the branch summary table
  • Update main branch description to state it uses the same four CI gates plus release flow
  • Clarify step 2 of the release flow so it notes that the four main gates are enforced at the branch-protection layer and block merging until green
docs/GIT-GITHUB-GUIDE.md
Update the release-please recovery runbook so the empty-feat release-trigger flow explicitly requires waiting for all main status checks. docs/_base/RUNBOOKS.md

Possibly linked issues


Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link
Copy Markdown

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@w7-mgfcode w7-mgfcode merged commit c3e911d into dev May 14, 2026
8 checks passed
@w7-mgfcode w7-mgfcode deleted the chore/ci-tighten-main-branch-protection branch May 14, 2026 03:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant