feat: implement issue #409 — Compliance: ruleset-drift-pr-quality-require_last_push_approval

[don-petry]

Closes #409

Implemented by dev-lead agent. Please review.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 43 minutes

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?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 956f3cba-c0db-417d-ac1e-112691bbc773

📥 Commits

Reviewing files that changed from the base of the PR and between 825bece and a351c83.

📒 Files selected for processing (1)

• tests/scripts/apply-rulesets.test.sh

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch dev-lead/issue-409-20260717-1355

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[gemini-code-assist]

Code Review

This pull request introduces a new Bash test script, tests/scripts/apply-rulesets.test.sh, which stubs the gh CLI to verify that the apply-rulesets.sh script correctly outputs the expected PR quality ruleset parameters during a dry run. The review feedback suggests several improvements to make the script more robust: adding a guard to ensure mktemp -d successfully creates a temporary directory before writing to it, enabling set -e to exit immediately on errors, and safely capturing the exit status of the dry-run command under set -e.

[gemini-code-assist]

If mktemp -d fails, STUB_DIR will be empty. Since set -e is not enabled in this script, execution will continue and attempt to write the stub to /gh (since "$STUB_DIR/gh" resolves to /gh), which can cause permission errors or write to the root directory if run as root. Adding a guard to check that STUB_DIR is non-empty and exists prevents this.

Suggested change

	STUB_DIR="$(mktemp -d)"
	trap 'rm -rf "$STUB_DIR"' EXIT
	STUB_DIR="$(mktemp -d)"
	if [[ -z "${STUB_DIR:-}" || ! -d "$STUB_DIR" ]]; then
	echo "not ok - failed to create temporary directory"
	exit 1
	fi
	trap 'rm -rf "$STUB_DIR"' EXIT

[don-petry]

Fixed in tests/scripts/apply-rulesets.test.sh: added a guard immediately after the mktemp -d call that checks STUB_DIR is non-empty and is a real directory, printing not ok and exiting 1 if either condition fails. The trap is now placed after the guard so it only runs when the directory was successfully created.

[Copilot]

Pull request overview

Adds a shell test that guards Broodly’s repo-ruleset automation against future drift in the pr-quality ruleset—specifically ensuring require_last_push_approval remains codified as true, as required by compliance issue #409.

Changes:

• Adds tests/scripts/apply-rulesets.test.sh to run scripts/apply-rulesets.sh in --dry-run --force mode.
• Stubs the gh CLI so the test is network-free and does not require real GitHub credentials.
• Asserts the emitted pr-quality ruleset payload includes the required pull request parameters (including require_last_push_approval: true).

[don-petry]

Dev-Lead — review-changes (applied)

Changes committed and pushed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[don-petry]

Dev-Lead — fix-bot-comment (no-changes)

Agent reasoning

| Component | Status | Findings |
|-----------|--------|----------|
| **SonarCloud Quality Gate** | ✅ PASSED | 0 new issues, 0 security hotspots, no coverage/duplication concerns |
| **Test Script Execution** | ✅ PASSED | All 6 assertions pass (ruleset parameters verified) |
| **Code Review (gemini-code-assist)** | ✅ OK | Suggestions already implemented: mktemp guard (lines 55-58), set -e enabled (line 16), safe exit capture (line 81) |
| **Tier 1 CI Blockers** | ⚠️ 2 failures | dev-lead/dispatch (fetch_pr_context error), review/review (cancelled) — both are CI infrastructure issues, not code issues |
**Conclusion:**
There are **no actionable code issues** to fix. The SonarCloud bot's quality gate passed with zero issues, the test script runs successfully, and all code quality standards are met. The Tier 1 CI blockers (workflow failures) are infrastructure-related automation issues, not code defects in the PR.
**No code changes required.**
The PR is ready from a code quality and testing perspective. The CI workflow failures appear to be temporary infrastructure issues with fetching PR review metadata and are separate from the code review process.

[don-petry]

Closing as part of the 50-PR cap drain. The dev-lead fix-loop repairs #1340 (self-cancellation), #1290 (comment-inertness) and #806 (thread-resolution) have all landed, so this deadlocked PR can be regenerated cleanly through the repaired loop. The driving issue stays open and its dev-lead label is re-fired — no work is lost.