During the investigation of PR #157 being stuck in BLOCKED state (REVIEW_REQUIRED despite all checks green), we discovered:
- The Auto-approve workflow only produced "push" event runs (with 0 jobs, conclusion failure) for commits on the branch.
- No
pull_request (synchronize) runs for Auto-approve appeared for the feature branch (unlike ci, security, DCO, etc.).
- Result: zero approving reviews were ever submitted by the bot. The PR required manual/ruleset intervention.
This is the deeper manifestation of the known "PR touches workflows" problem (see #148, #153, and auto-approve.yml wf-changes logic).
We used a temporary ruleset user bypass + gh pr merge --admin (per ci-branch-protection emergency hatch) to unblock, then removed the bypass.
Not addressed:
- A robust way for infra PRs (especially ones changing auto-approve itself) to get the required review without falling back to bypass/admin.
- The approval step itself (using GITHUB_TOKEN) isn't executing reliably in this scenario.
- The
require_last_push_approval: true added extra friction ("New changes require approval from someone other than the last pusher") even with bypass.
Previous workarounds only addressed the auto-merge GraphQL step, not the fundamental review submission.
Related skills/docs:
- patchloom-vscode-contrib/SKILL.md (multiple mentions of workflow-touching PRs and App token limitations)
- ci-branch-protection/SKILL.md (auto-approve lessons, emergency bypass)
Suggested improvements to consider:
- Separate the approval logic (e.g. always run approve with GITHUB_TOKEN in a way that works, or use a distinct mechanism).
- Document a standard process for PRs that modify auto-approve.yml (e.g. manual approval by maintainer, or temporary bypass + cleanup PR).
- Re-evaluate
require_last_push_approval for solo maintainer friction on self-PRs.
- Make the wf-changes check also affect whether we attempt the approve step or use a different token/approach.
This was noticed in detail during the session but addressed with a one-off ruleset intervention rather than a tracked improvement.
During the investigation of PR #157 being stuck in BLOCKED state (REVIEW_REQUIRED despite all checks green), we discovered:
pull_request(synchronize) runs for Auto-approve appeared for the feature branch (unlike ci, security, DCO, etc.).This is the deeper manifestation of the known "PR touches workflows" problem (see #148, #153, and auto-approve.yml wf-changes logic).
We used a temporary ruleset user bypass +
gh pr merge --admin(per ci-branch-protection emergency hatch) to unblock, then removed the bypass.Not addressed:
require_last_push_approval: trueadded extra friction ("New changes require approval from someone other than the last pusher") even with bypass.Previous workarounds only addressed the auto-merge GraphQL step, not the fundamental review submission.
Related skills/docs:
Suggested improvements to consider:
require_last_push_approvalfor solo maintainer friction on self-PRs.This was noticed in detail during the session but addressed with a one-off ruleset intervention rather than a tracked improvement.