Document develop ruleset omitting branch-up-to-date check#143
Merged
Conversation
The develop branch ruleset's `strict_required_status_checks_policy` was flipped from `true` to `false` server-side today, matching main. This unblocks bot auto-merge when two PRs against develop land within the same minute and the first pushes the second into BEHIND state. Observed in #141 (nuget-deps → develop sat OPEN with all checks green because PR #140 had merged into develop ~10 s after #141 opened). Update the Branching Model bullet that previously stated develop kept the "up to date" check on; now both rulesets omit it for two distinct reasons: - Main: graph-based reachability fails after every develop → main merge release because forward-only develop never re-acquires main's new tip commit. - Develop: bot auto-merge incompatibility. The merge-bot enables auto-merge once on opened/reopened and never auto-updates the head ref, so a sibling-merge race leaves the second PR permanently BEHIND while auto-merge waits for a strict policy that nothing satisfies. Also add a do-not-reintroduce warning and cross-reference the relaxed flag from the parallel-bots bullet so a future template sync doesn't silently put the flag back. The matching change in the upstream template is tracked at ptr727/ProjectTemplate#82.
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the repository’s canonical contributor/agent documentation to reflect that the develop branch ruleset no longer requires PR branches to be “up to date before merging” (matching the already-relaxed main ruleset), and documents the distinct rationale for each branch.
Changes:
- Document that both
mainanddeveloprulesets havestrict_required_status_checks_policy: false, with separate explanations for why each omits the “up to date” requirement. - Add an explicit warning not to reintroduce the strict flag on
developdue to bot auto-merge race conditions. - Thread the “strict off” rationale into the parallel-bots section so future template syncs don’t silently revert the intent.
3 tasks
ptr727
added a commit
that referenced
this pull request
May 13, 2026
Release: document develop ruleset strict-flag removal (#143)
This was referenced May 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
AGENTS.md"Branching Model" section to reflect that the develop ruleset'sstrict_required_status_checks_policywas flipped fromtruetofalseserver-side today (rule id 12277308).Why
PR #141 sat OPEN with all checks green and auto-merge armed because a sibling Dependabot PR (#140) against develop merged ~10 seconds after #141 opened, pushing #141 into
mergeStateStatus: BEHIND. Auto-merge cannot fire while the strict flag is on, and nothing in the merge-bot (see merge-bot-pull-request.yml) auto-updates a bot branch in that window. The matching main-side PR (#142) merged cleanly because main's ruleset already had strict off — that asymmetry is the smoking gun.Upstream template
The yesterday-synced ProjectTemplate ruleset has the same
strict_required_status_checks_policy: trueon develop. Filed ptr727/ProjectTemplate#82 so the template gets the matching change and downstream consumers don't reintroduce the flag on their next sync.Scope
Docs only. The actual ruleset flip was applied server-side and is already verifiable via
gh api repos/ptr727/LanguageTags/rules/branches/develop→strict_required_status_checks_policy: false. PR #141 itself was unblocked separately (gh api -X PUT .../pulls/141/update-branch, re-arm auto-merge, merged at 14:45:33Z).Test plan
Check pull request workflow statusgreen.gh pr update-branch. (Will surface organically on the next daily run.)