Skip to content

Develop ruleset strict "branches up to date" flag stalls bot auto-merge when sibling PR lands mid-CI #82

Description

@ptr727

Problem

The develop branch ruleset in this template (rule id 15886282 in ptr727/ProjectTemplate) has required_status_checks.strict_required_status_checks_policy: true — "Require branches to be up to date before merging". This silently breaks bot auto-merge for any downstream repo that adopts the template and has two bot PRs against develop land within the same minute. The first to merge pushes the second into mergeStateStatus: BEHIND; GitHub's auto-merge will not fire while strict is on; the merge-bot in .github/workflows/merge-bot-pull-request.yml only enables auto-merge on opened/reopened and never auto-updates a bot branch. The second PR sits OPEN with all checks green, indefinitely.

Repro from a downstream consumer

Observed today in ptr727/LanguageTags, which was synced to this template yesterday in LanguageTags#130. The first racing Dependabot batch after the sync hit the bug.

PR in question: ptr727/LanguageTags#141 — "Bump the nuget-deps group with 4 updates → develop".

Timeline (UTC, 2026-05-13):

Time Event
02:51:49 PR #140 (actions-deps → develop) opened
02:55:13 PR #141 (nuget-deps → develop) opened
02:55:25 Auto-merge enabled on #141 by ptr727-codegen[bot] (squash)
02:55:36 PR #140 merged into develop — develop advances
02:57:16 #141 CI finishes green
02:58:53 #141 `Check pull request workflow status` reports SUCCESS

`gh api repos/ptr727/LanguageTags/compare/develop...dependabot/nuget/develop/nuget-deps-4eb3dd8c5d` → `{ahead_by: 1, behind_by: 1, status: "diverged"}`. PR stays `mergeStateStatus: BEHIND` with auto-merge armed.

Contrast: the sibling Dependabot PR against `main` from the same Dependabot run — `ptr727/LanguageTags#142` — merged cleanly, because main's ruleset has the strict flag off.

Why the workflow doesn't recover on its own

  • `merge-bot-pull-request.yml` only enables auto-merge on `opened`/`reopened`; `synchronize` events go to the `disable-auto-merge-on-maintainer-push` job, not anything that updates the branch. This is intentional behavior, well-documented in the workflow comments.
  • Dependabot's built-in rebase isn't real-time; it triggers on conflict, schedule, or `@dependabot rebase` comment — none of which fire 10 s after a sibling PR merges.
  • GitHub's auto-merge does not auto-update the head branch.

Recommended template change

Set `strict_required_status_checks_policy: false` on the `develop` ruleset in `ptr727/ProjectTemplate` (id 15886282), matching `main`. Every other rule stays: `deletion`, `non_fast_forward`, `required_linear_history`, `required_signatures`, `pull_request` with `allowed_merge_methods: ["squash"]`, the `Check pull request workflow status` required status check, `copilot_code_review`, `dismiss_stale_reviews_on_push`.

What you keep:

  • Squash mechanics: a squash merge always rebases the PR's diff onto develop's current tip; linear history still enforced by `required_linear_history`.
  • Textual conflict detection: `mergeable: CONFLICTING` still blocks merge regardless of strict.
  • CI gating: `Check pull request workflow status` is still required.
  • Signature / linear-history / deletion / non-fast-forward protections, maintainer-push disable behavior, develop → main release flow.

What you lose: pre-merge detection of semantic-but-not-textual conflicts (where two PRs touch different files but combine to break a build). Those now surface on the post-merge develop CI run, which already runs on every push to develop. For Dependabot bumps and codegen template syncs — the PRs that race here — the file footprint is narrow enough that real combinations are caught textually anyway.

The change can be applied via `gh api -X PUT repos/ptr727/ProjectTemplate/rulesets/15886282 --input ` (the PUT replaces the whole ruleset, so fetch first, flip the flag, send back) or via the GitHub UI under Settings → Rules → Rulesets → develop → uncheck "Require branches to be up to date before merging".

Downstream docs to update in lockstep

`ptr727/LanguageTags` was patched locally today as part of this same investigation (ruleset flipped, AGENTS.md "Branching Model" section updated to document why both rulesets now omit the strict flag). The matching AGENTS.md update in this template should be made when the ruleset change lands, so the next downstream template sync brings the corrected doc forward. The LanguageTags doc change is the canonical phrasing — happy to PR it back here once this issue is triaged.

Acceptance

  • `gh api repos/ptr727/ProjectTemplate/rules/branches/develop` shows `strict_required_status_checks_policy: false` with every other rule unchanged.
  • Template's AGENTS.md "Branching Model" updated to match LanguageTags' new phrasing (both rulesets omit strict; develop's reason is bot auto-merge race-proofing).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions