Auto-created forward-merge pull requests (Phase 2 of MDBF-895)

Context

Phase 1 (MDBF-895) gives us a chain-health checker and a PR check that detects forward-merge conflicts and notifies developers. PLC goal: new Buildbot always green / branch protection / automerge. Phase 2 automates the mechanical part of clean forward-merges while keeping every merge decision under human review.

The tool should run early in the release cycle, so merge overhead is absorbed continuously in small batches rather than accumulating into the end-of-cycle merge pressure we have today.

Entry criteria: Phase 1 deployed on MariaDB/server; chain green and stable for an agreed period (proposal: 4 weeks with no week-long blockages).

Mechanism

Batching model

• Merge PRs are created per scheduled run, not per push: each PR batches all commits pending on that edge since the last merge.
• The chain advances up to the first breaking change and stops there for that edge. The likely author is contacted to triage: if the fault is elsewhere, they reassign; otherwise, they resolve and merge the updated changes themselves.
• Once the blocking change is resolved, the tool resumes with subsequent changes in the same pattern.

Workflow

• Runs on a schedule (default: daily, configurable) and on manual trigger (workflow_dispatch / gh CLI — covers Monty's command-line requirement).
• For each edge in the configured chain with pending commits:
  • If the synthetic merge is clean: auto-create a merge PR from SOURCE to TARGET on a generated branch (proposal: bb-merge-SOURCE-to-TARGET), with a description listing the merged commits and their authors.
  • If there are merge conflicts, no PR is created; the Phase 1 notification applies. Optionally push the conflicted state to a bb-merge-SOURCE-to-TARGET-conflict branch so the resolving developer starts from it.
• CI (Buildbot via branch protection) runs on the merge PR like any other PR.
• A developer reviews and merges. No automatic merging in this phase.
• If the PR goes stale (the target branch moves), the job recreates/rebases it on the next run.

Open questions

• Cadence: daily? twice daily? weekly? per-edge overrides? (Cadence only affects history granularity — conflict detection stays continuous via the Phase 1 chain-health checker.)
• Who is the default owner/assignee of a merge PR — the authors of the merged commits, a rotating merge captain, or RM per branch?
• Attribution: merge commit author/committer conventions.
• Should a clean-but-CI-red merge PR notify like a conflict?

Test cases

• Commit to 10.6, observe the merge PR auto-created to 10.11 with the correct commit list.
• Batch of N commits with a breaking change at commit k: PR contains commits before k; chain stops at k; author notified for triage; after resolution, the next run picks up the remainder.
• Conflicting commit: no PR, notification fired, optional conflict branch pushed.
• Target branch advances after PR creation: PR is rebased/recreated next run.
• Manual CLI trigger creates PRs immediately.