Declare require_extra_approval_for_unattributed_changes in Rulesets

[ptr727]

Fixes #926.

GitHub added the pull_request ruleset parameter require_extra_approval_for_unattributed_changes and enabled it by default on every new and existing ruleset (it requires one more approval than the configured threshold when Copilot opens a PR under its own app identity rather than attributed to a person). It was absent from the hub's committed payloads, so configure.sh check flagged every repo carrying it, including the hub's own develop/main rulesets, as drift, even though nothing was ever actually misconfigured.

Confirmed live true on both of the hub's own rulesets and on Blog's before choosing the value, so this commits what GitHub already applies fleet-wide rather than picking a new default. It also has no live behavioral effect today, since it only matters once required_approving_review_count is above zero, which is 0 on every ruleset checked so far.

One correction to the issue's ask: repo-config/operational/develop.json carries no pull_request rule at all (operational repos take direct signed pushes to develop, no PR gate), so there's no pull_request parameters object there to add the key to. Only develop.json and main.json changed.

Verified: repo-config/configure.sh check ptr727/ProjectTemplate release now passes clean (previously would flag develop/main rule pull_request parameters as mismatched, matching the issue's own repro against Blog).

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Declare GitHub ruleset flag for extra approval on unattributed PR changes

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Add GitHub’s new ruleset parameter to committed ruleset payloads
• Align repo-config with GitHub’s fleet-default behavior to avoid drift alerts
• Unblock configure.sh check by eliminating false-positive mismatches

Diagram

graph TD
  D["repo-config/develop.json"] --> C["configure.sh check"] --> G{{"GitHub rulesets"}} --> R["Repos/rulesets"]
  M["repo-config/main.json"] --> C --> G --> R
  subgraph Legend
    direction LR
    _file["Config file"] ~~~ _tool["CLI/script"] ~~~ _ext{{"External system"}}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Teach drift checker to ignore unknown/defaulted ruleset keys

• ➕ Avoids frequent config churn as GitHub adds new default parameters
• ➕ Prevents future false-positive drift from newly introduced fields
• ➖ Risk of masking real config drift for newly added but important keys
• ➖ Requires careful policy around which keys are safe to ignore

2. Centralize ruleset defaults in a shared template generator

• ➕ Single place to update when GitHub introduces new effective defaults
• ➕ Reduces duplication across per-branch ruleset payloads
• ➖ More refactor work than warranted for a one-field fix
• ➖ Adds indirection to otherwise straightforward JSON payloads

Recommendation: The current approach—explicitly committing the GitHub-applied default (require_extra_approval_for_unattributed_changes: true)—is the best immediate fix because it restores configure.sh check signal-to-noise without changing validation semantics. Longer-term, consider selectively handling GitHub-introduced default keys in the drift checker if this becomes a recurring pattern.

Files changed (2) +2 / -0

Other (2) +2 / -0

develop.jsonAdd missing ruleset parameter for unattributed-change approvals +1/-0

Add missing ruleset parameter for unattributed-change approvals

• Declares 'require_extra_approval_for_unattributed_changes: true' in the 'pull_request' ruleset parameters to match GitHub’s effective default and prevent drift reports.

repo-config/develop.json

main.jsonAdd missing ruleset parameter for unattributed-change approvals +1/-0

Add missing ruleset parameter for unattributed-change approvals

• Declares 'require_extra_approval_for_unattributed_changes: true' in the 'pull_request' ruleset parameters to match GitHub’s effective default and prevent drift reports.

repo-config/main.json

[Copilot]

🟢 Approval recommended

The change is a minimal, verified payload sync that aligns the committed ruleset parameters with GitHub’s live defaults and does not introduce new behavior beyond removing spurious drift.

Pull request overview

This pull request updates the hub’s committed GitHub ruleset payloads to explicitly include the newly added pull_request ruleset parameter require_extra_approval_for_unattributed_changes, matching GitHub’s now-default live configuration and eliminating false-positive drift from repo-config/configure.sh check.

Changes:

• Add "require_extra_approval_for_unattributed_changes": true to the pull_request rule parameters in repo-config/main.json.
• Add "require_extra_approval_for_unattributed_changes": true to the pull_request rule parameters in repo-config/develop.json.

File summaries

File	Description
repo-config/main.json	Declares the new pull_request parameter in the canonical main ruleset payload to match GitHub’s live default and avoid drift reports.
repo-config/develop.json	Declares the same new pull_request parameter in the canonical develop ruleset payload for release-model repos, aligning payload vs. live ruleset state.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can turn these tips off under Display preferences

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[coderabbitai]

Warning

Review limit reached

@ptr727, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 3 minutes

Limit details: You’ve used all 10 included reviews currently available.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 222d1970-b88d-4db6-a092-4ab022fcf84f

📥 Commits

Reviewing files that changed from the base of the PR and between fc489dd and 6f799fb.

📒 Files selected for processing (2)

• repo-config/develop.json
• repo-config/main.json

---

_{Comment @coderabbitai help to get the list of available commands.}