molecule-ai/molecule-core
53
0
Fork 2
Code Issues 190 Pull Requests 45 Actions Packages Projects Releases Wiki Activity

[ci-governance] Owner BP flip: make qa-review + security-review + reserved-path-review merge-blocking on main #3141

New Issue
Open
opened 2026-06-22 03:09:49 +00:00 by core-devops · 0 comments
core-devops commented 2026-06-22 03:09:49 +00:00
Member
Copy Link
Copy Source

Owner action: add qa-review / security-review / reserved-path-review to branch protection

CTO-authorized: make the three review gates truly merge-blocking on main.

Background / mechanism analysis

These three checks post commit statuses today but are NOT in branch_protections/main.status_check_contexts, so a PR merges once its 4 actually-required contexts are green regardless of the review verdicts (proven: #3131 merged with qa-review red).

Path A (sentinel wiring) is NOT viable. CI / all-required is a plain needs: aggregator over CI's OWN jobs (ci.yml). Gitea Actions has no cross-workflow needs:, and the prior poll-the-status-API design was deliberately removed (runner-squat RCA, 2026-06-01). The review contexts are emitted by separate workflow files on pull_request_target / pull_request_review events, so the sentinel structurally cannot gate them. This is exactly why ci-required-drift.py F4 exists (cross-workflow required contexts must live in BP directly + have a live emitter).

Path B (owner BP flip) is the only mechanism.

The exact owner action (after the SSOT PR merges)

Order matters: merge the required-contexts.txt PR FIRST, then PATCH BP. (lint_no_coe_on_required fails if live_BP - allowlist is non-empty — allowlist must be a superset of BP.)

PATCH branch_protections/main.status_check_contexts to ADD (keep existing 4):

qa-review / approved (pull_request_target)
security-review / approved (pull_request_target)
reserved-path-review / reserved-path-review (pull_request_target)

Full target list (7):

  • CI / all-required (pull_request)
  • E2E API Smoke Test / E2E API Smoke Test (pull_request)
  • Handlers Postgres Integration / Handlers Postgres Integration (pull_request)
  • Secret scan / Scan diff for credential-shaped strings (pull_request)
  • qa-review / approved (pull_request_target)
  • security-review / approved (pull_request_target)
  • reserved-path-review / reserved-path-review (pull_request_target)

Why (pull_request_target) (not (pull_request_review))

The (pull_request_target) variant fires on every PR open/synchronize and starts RED (review-check.sh exits 1 → job conclusion publishes failure) when there is no APPROVE — fail-closed, no false-green, no deadlock. The pull_request_review path explicitly RE-POSTS the same (pull_request_target) context to flip it green on a genuine APPROVE (mirrors the working sop-checklist pattern). Requiring (pull_request_review) instead would deadlock (absent until a review is submitted = pending forever).

Fail-closed proof

  • No review yet → qa-review / approved (pull_request_target) = failure (red) → BLOCKS.
  • Genuine non-author APPROVE → success (green) → unblocks.

reserved-path-review only goes red for PRs touching .gitea/reserved-paths.txt; otherwise it posts success — so it does not block ordinary PRs.

## Owner action: add qa-review / security-review / reserved-path-review to branch protection CTO-authorized: make the three review gates **truly merge-blocking** on `main`. ### Background / mechanism analysis These three checks post commit statuses today but are NOT in `branch_protections/main.status_check_contexts`, so a PR merges once its 4 actually-required contexts are green regardless of the review verdicts (proven: #3131 merged with qa-review red). **Path A (sentinel wiring) is NOT viable.** `CI / all-required` is a plain `needs:` aggregator over CI's OWN jobs (`ci.yml`). Gitea Actions has no cross-workflow `needs:`, and the prior poll-the-status-API design was deliberately removed (runner-squat RCA, 2026-06-01). The review contexts are emitted by separate workflow files on `pull_request_target` / `pull_request_review` events, so the sentinel structurally cannot gate them. This is exactly why `ci-required-drift.py` F4 exists (cross-workflow required contexts must live in BP directly + have a live emitter). **Path B (owner BP flip) is the only mechanism.** ### The exact owner action (after the SSOT PR merges) Order matters: merge the `required-contexts.txt` PR FIRST, then PATCH BP. (`lint_no_coe_on_required` fails if `live_BP - allowlist` is non-empty — allowlist must be a superset of BP.) PATCH `branch_protections/main.status_check_contexts` to ADD (keep existing 4): ``` qa-review / approved (pull_request_target) security-review / approved (pull_request_target) reserved-path-review / reserved-path-review (pull_request_target) ``` Full target list (7): - CI / all-required (pull_request) - E2E API Smoke Test / E2E API Smoke Test (pull_request) - Handlers Postgres Integration / Handlers Postgres Integration (pull_request) - Secret scan / Scan diff for credential-shaped strings (pull_request) - qa-review / approved (pull_request_target) - security-review / approved (pull_request_target) - reserved-path-review / reserved-path-review (pull_request_target) ### Why `(pull_request_target)` (not `(pull_request_review)`) The `(pull_request_target)` variant fires on every PR open/synchronize and starts RED (review-check.sh exits 1 → job conclusion publishes `failure`) when there is no APPROVE — fail-closed, no false-green, no deadlock. The `pull_request_review` path explicitly RE-POSTS the same `(pull_request_target)` context to flip it green on a genuine APPROVE (mirrors the working `sop-checklist` pattern). Requiring `(pull_request_review)` instead would deadlock (absent until a review is submitted = pending forever). ### Fail-closed proof - No review yet → `qa-review / approved (pull_request_target)` = failure (red) → BLOCKS. - Genuine non-author APPROVE → success (green) → unblocks. reserved-path-review only goes red for PRs touching `.gitea/reserved-paths.txt`; otherwise it posts success — so it does not block ordinary PRs.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 platform/go
Go platform test issues
 release-blocker
Blocks the staging→main promotion / a release
 release-test
security
test-label-sre
tier:high
High risk per dev-sop §SOP-6 — ceo only, 24h cooldown
 tier:low
Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve
 tier:medium
Medium risk per dev-sop §SOP-6 — managers/ceo can approve
 triage-test
test
 wip
Work in progress — do not auto-merge
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#3141
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?