Repository navigation
Release PRs cannot satisfy branch protection — five admin overrides in one session #819
Description
Every release-please PR is structurally unmergeable through the normal path, and the only way past it is gh pr merge --admin.
On 2026-08-14 that happened five times: mctl-api #144 and #163, mctl-portal #60, mctl-agent #52, mctl-telegram #352.
Why it cannot pass
author = app/github-actions
review = REVIEW_REQUIRED
state = BLOCKED
Branch protection requires an approving review. claude-review.yml does not review bot-actor PRs, so no review ever arrives. On some repos not a single check reports on the release branch at all ("no checks reported"), so required contexts are missing too.
Nothing about waiting helps: the condition can never be met.
Why it matters
The override works, so the cost is not lost time — it is that routinely bypassing branch protection makes the bypass unremarkable. The one time a release PR carries something it should not, the same reflex will wave it through. This session already had a case worth catching: mctl-api 4.32.0 bundled an unreleased MCP feature that had been sitting in main for a week, and that only surfaced because the changelog was read out loud before merging.
Options
- Exempt release-please from the review requirement — narrow, but weakens protection on exactly the PRs that touch version manifests.
- Make the required checks run on release branches so the gate is satisfiable, and drop the review requirement only for this author.
validatealready runs elsewhere; the release branch just is not covered. - Have a bot approve bot PRs — least appealing, an approval nobody read.
(2) looks closest to honest: the checks genuinely run, and only the human-review requirement is relaxed for a PR whose entire content is generated.
Worth deciding once and applying across all 16 repos rather than per-repo as each one bites.
Activity
ci: skip commit-lint on release-please branches
mashkovd commentedon Aug 15, 2026
Фаза 1 закрыта. Диагноз в задаче верен в корне и неточен в следствии — ниже поправки, они меняют то, что надо делать дальше.
Поправка 1: дело не в required checks
В задаче записано, что релизные PR не проходят из-за «no checks reported». Проверил фактическую защиту веток:
contexts = null)test,dockerRequired checks есть только у mctl-telegram. В остальных восьми единственный гейт — одобряющее ревью. Красные чеки мержу не мешали; мешало отсутствие APPROVE от
claude[bot].Корневая причина в задаче названа правильно:
release-please-actionбез входаtoken:работает под дефолтнымGITHUB_TOKEN, GitHub не порождает workflow-события, иclaude-review.ymlне стартует. Но следствие из этого — «некому одобрить», а не «не отчитались чеки».Поправка 2: на mctl-agents ломалось не то, что предполагалось
В плане было: срабатывает дедуп-ветка claude-review («этот коммит уже отревьюен») и выходит с кодом 1. Это не так. По шагам джоба на #141 видно, что дедуп не сработал,
Checkoutи само ревью отработали, а упал шагClassify reviewer outcome. Причина в логе:mctl-agents уже перешёл на App-токен (PR #102), поэтому actor запуска — App
mctl-agents.claude-code-actionпроверяет actor, а не автора PR; автор (mctl-app[bot]) вallowed-botsбыл, поэтому причина и выглядела необъяснимой.Правка reusable-workflow не нужна — дедуп-ветка исправна.
Что сделано
commit-lintпропускается на веткахrelease-please--branches--*. Релизный PR несёт ровно один коммитchore(main): release x.y.z, который по определению не releasable: он и есть релиз. Смержен обычным merge-коммитом,--adminне понадобился.mctl-agentsвallowed-bots.Новое ограничение, которого в задаче нет
PR #175 пришлось мержить через
--admin, и это не небрежность, а структурная невозможность. Любой PR, меняющийclaude-review.yml, не может быть отревьюен ботом:Claude App не выдаёт токен, пока файл воркфлоу на ветке отличается от версии в default-ветке. При этом автор PR не может одобрить собственный PR (правило GitHub). То есть одобрить такой PR не может никто.
Поэтому изменения были разделены на два PR: чтобы ручное одобрение оставалось исключением на один файл, а не расползалось на весь релизный поток.
Для фазы 3 это важно: убрать из
AGENTS.mdнадо исключение про релизные PR, но на его место должно встать другое, настоящее — «PR, меняющиеclaude-review.yml, требуют--admin, потому что ревьюер не может ревьюить собственный воркфлоу». Иначе исключение просто исчезнет из документации, оставшись в практике.Фаза 2 — начинать рано
Критерий фазы 1: следующий релизный PR mctl-agents должен собрать зелёные чеки, получить APPROVE от
claude[bot]и смержиться обычнымgh pr merge --merge. Пока такого PR не появилось, доказательства нет, а раскатывать на 15 репозиториев непроверенное — это тот самый рефлекс, о котором задача и написана.Одна находка для фазы 2 уже есть и её стоит внести в чек-лист: слаг
mctl-agentsпридётся добавлять вallowed-botsкаждого репозитория вместе с App-токеном. Как только release-please там начинает работать под App, actor меняется и claude-review падает с той же ошибкой «non-human actor». Без этого раскатка воспроизведёт ту же красноту в 15 местах.