werkregie/doc/prs/2026-10-20-PR#94-own-pr-merge.md

PR#94: Mergen for the User's Own Pull Request That Has Its Approvals

Version: minor

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

Problem

"Du bist dran" shows the user's own pull request as Mergen only when another human approved it. The branch protection of the base branch decides what a merge needs, not werkregie: e.g. mi/werkdock needs no approval and only the check werkator, and the repositories with werkrevisor accept the approval of ai-reviewer. Such a pull request waits for the user to merge it, but werkregie shows it as Wartet auf Review or not at all.

When main moved on since the branch left it, the user rebases first and merges after the build of the rebased head.

Non-Goals

• No change for an agent's pull request; its Mergen stays as in werkregie PR#17.
• No merge or rebase by werkregie; the row links the pull request, as before.
• No check of block_on_outdated_branch, which Gitea gives only to an admin of the repository: a branch behind its base gets the hint to rebase in each case.

Specification

Feature: the user's own pull request that the branch protection lets merge

Scenario#94.01: the approvals and the required checks are there

… so that the user sees the pull request that waits for the merge alone.

• Given the user's own pull request on main, whose branch protection asks for 1 approval and the check werkator, with the approval of ai-reviewer for the head commit, werkator green, no conflict, and main unchanged since the branch left it
• When werkregie reads the pull request
• Then "Du bist dran" shows it under Mergen with "approved von ai-reviewer"

Verified by

• GiteaSourceTest "the user's own pull request with the approvals and checks of its branch protection is to merge"
• GiteaSourceFetchTest "the open pull requests of the user, each with its statuses, reviews and flags"

Scenario#94.02: no approval needed

… so that a repository without a review also shows the merge.

• Given the user's own pull request on a main that asks for no approval, with all required checks green
• When werkregie reads the pull request
• Then "Du bist dran" shows it under Mergen with "kein Approval nötig"

Verified by

• GiteaSourceTest "a branch protection without approvals needs only the checks"

Scenario#94.03: main moved on

… so that the user rebases before the merge.

• Given the pull request of Scenario#94.01, and main has a commit that the branch lacks
• When werkregie reads the pull request
• Then "Du bist dran" shows it under Mergen with "approved von ai-reviewer · hinter main: rebasen, dann mergen"

Verified by

• GiteaSourceTest "a branch behind its base is to rebase first"

Scenario#94.04: an approval or a required check is missing

… so that Mergen comes only when Gitea lets the user merge.

• Given the user's own pull request whose branch protection asks for 2 approvals and the checks werkator and ai-review/gate
• When werkregie reads it with only 1 approval, or without a green ai-review/gate, or with an automerge scheduled
• Then it shows no Mergen

Verified by

• GiteaSourceTest "a missing approval, a missing check or a scheduled automerge is no merge"

Scenario#94.05: no branch protection known

… so that an unprotected branch keeps the rule of before.

• Given the user's own pull request on a branch without protection, or one whose branch werkregie cannot read
• When werkregie reads it
• Then it shows Mergen only for an approval by another human, as before

Verified by

• GiteaSourceTest "without a branch protection the approval of another human is to merge"
• GiteaSourceTest "the branch protection comes from the base branch; an unprotected branch has none"

Solution

For each ready pull request of the user's own, GiteaSource reads the base branch, GET /repos/{repo}/branches/{base}: its required_approvals and, with enable_status_check, its status_check_contexts, which may be glob patterns. Only official approvals of the head commit count, as Gitea counts them. The automerge check, one request for the timeline, now runs also for the user's own pull request without an approval. A branch is behind when the pull request's merge_base is not the head of its base, base.sha.

Release Notes

"Du bist dran" shows your own pull request under Mergen as soon as its branch protection lets you merge it, with the hint to rebase first when main moved on.

Open Questions

• Which pull requests are the user's own? Those whose author is the user of the token of the Gitea instance, GET /api/v1/user, e.g. mi or hsh-michaelhoennig. werkregie treats every other pull request as an agent's pull request, also one of a colleague; this PR does not change that.

Follow-up PRs

• TODO.colleague: werkregie shows a colleague's approved and green pull request as Mergen for the user. The colleague merges it, not the user; so werkregie is to tell a colleague from an agent.