Enforce already-landed PR gate before review approval or merge #294

Closed
opened 2026-07-07 00:21:34 -05:00 by jcwalker3 · 0 comments
Owner

Reviewer workflows must not approve or attempt to merge PRs whose head commit is already an ancestor of the target branch.

Observed failure mode:

A reviewer workflow selected a PR, validated it, approved it, and attempted to merge it. The merge failed with a Gitea API error because the PR head commit had already landed on master. The correct behavior should have been to stop before approval and enter an ALREADY_LANDED_RECONCILE_REQUIRED state.

Required behavior:

  1. After selecting a PR and pinning the candidate head SHA, the workflow must fetch the target branch from the remote.

  2. The workflow must record the target branch SHA used for ancestry checks.

  3. The workflow must check whether the PR head SHA is already an ancestor of the target branch.

  4. If already landed:

    • do not validate as a normal merge candidate
    • do not approve
    • do not request changes unless there is a real blocker
    • do not call the merge API
    • produce an ALREADY_LANDED_RECONCILE_REQUIRED handoff
  5. The reconciliation handoff must include:

    • PR number/title
    • candidate head SHA
    • target branch
    • target branch SHA
    • ancestor proof
    • linked issue status
    • recommended reconciliation action
  6. Any PR close, issue close, or comment mutation must require separate exact capability proof.

  7. Final-report validation must reject APPROVED, MERGED, or READY_TO_MERGE states when the already-landed gate fired.

  8. Final-report validation must reject claims that the target branch was up to date unless the remote fetch and target SHA are reported.

Acceptance criteria:

  • Already-landed PRs cannot be approved.
  • Already-landed PRs cannot call the merge API.
  • Already-landed PRs produce a reconciliation handoff instead of a review/merge report.
  • Tests cover already-landed PR, normal mergeable PR, stale local target branch, changed PR head, and blocked close/comment capability.
  • Reports include target branch SHA used for the already-landed check.
Reviewer workflows must not approve or attempt to merge PRs whose head commit is already an ancestor of the target branch. Observed failure mode: A reviewer workflow selected a PR, validated it, approved it, and attempted to merge it. The merge failed with a Gitea API error because the PR head commit had already landed on `master`. The correct behavior should have been to stop before approval and enter an `ALREADY_LANDED_RECONCILE_REQUIRED` state. Required behavior: 1. After selecting a PR and pinning the candidate head SHA, the workflow must fetch the target branch from the remote. 2. The workflow must record the target branch SHA used for ancestry checks. 3. The workflow must check whether the PR head SHA is already an ancestor of the target branch. 4. If already landed: * do not validate as a normal merge candidate * do not approve * do not request changes unless there is a real blocker * do not call the merge API * produce an `ALREADY_LANDED_RECONCILE_REQUIRED` handoff 5. The reconciliation handoff must include: * PR number/title * candidate head SHA * target branch * target branch SHA * ancestor proof * linked issue status * recommended reconciliation action 6. Any PR close, issue close, or comment mutation must require separate exact capability proof. 7. Final-report validation must reject `APPROVED`, `MERGED`, or `READY_TO_MERGE` states when the already-landed gate fired. 8. Final-report validation must reject claims that the target branch was up to date unless the remote fetch and target SHA are reported. Acceptance criteria: * Already-landed PRs cannot be approved. * Already-landed PRs cannot call the merge API. * Already-landed PRs produce a reconciliation handoff instead of a review/merge report. * Tests cover already-landed PR, normal mergeable PR, stale local target branch, changed PR head, and blocked close/comment capability. * Reports include target branch SHA used for the already-landed check.
jcwalker3 added the status:in-progress label 2026-07-07 08:17:21 -05:00
sysadmin removed the status:in-progress label 2026-07-07 09:15:21 -05:00
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#294