fix(ci): let both bot PATs approve the release PR, no human needed - #9056
Conversation
The release PR was created with CI_BOT_PAT, so GitHub's self-approval forbade ci-bot from approving it; only CI_DEV_BOT_PAT approved and the branch protection's second required approval had to come from a human (see #9054). Create the PR with the installation token instead so the author is github-actions[bot], freeing both PAT identities to supply the two approvals: keep the dev-bot approve step and add a ci-bot approve step. Auto-merge (ci-bot) is unchanged.
|
✅ Qwen Triage finished — CI landed green on ✅ Qwen Triage 已完成 —— |
|
Thanks for the PR! Template looks good ✓ Problem: observed, not theoretical. #9054 (release v0.21.11) was authored by Direction: aligned — this removes mechanical toil, not a review gate: the release PR is machine-generated (version + CHANGELOG sync), and the human click was an artifact of the author identity, not a substantive checkpoint. This does touch release automation, so I checked the consumers that key on PR author before signing off on the direction: the safety precheck ( Size: not applicable — one workflow file, +17/−1, no core paths. Approach: the scope feels right. The alternatives I'd consider are all worse: a third bot PAT (more secret management), relaxing branch protection (weakens every PR), or admin-bypass merge (sidesteps the protection semantics). Making the installation token the author frees both existing PAT identities to supply the two approvals, and every hunk earns its place: the Risk: no elevated risk signals (none of the revert-correlated paths are touched). One honest callout: this removes the last human click from the release-sync merge path. That is the stated intent, and it's the release owner's tradeoff to make — flagging it for visibility, not as an objection. Moving on to code review. 🔍 中文说明感谢贡献! 模板完整 ✓ 问题:已观测到的真实问题,不是理论假设。#9054(v0.21.11 发布 PR)由 方向:对齐——这是去掉机械性操作,而不是绕过审查关卡:发布 PR 是机器生成的(版本号 + CHANGELOG 同步),那个人工点击只是作者身份导致的产物,不是实质性检查点。由于涉及发布自动化,我在认可方向前核查了所有按 PR author 分类的下游:安全预检( 规模:不适用——单个 workflow 文件,+17/−1,未触及核心路径。 方案:范围合理。我考虑过的替代方案都更差:第三个 bot PAT(增加 secret 管理负担)、放宽 branch protection(削弱所有 PR 的保护)、admin 绕过合并(绕开保护语义)。改用 installation token 作为作者后,两个现有 PAT 身份都空出来提供两个 approve,且每处改动都有必要: 风险:无升级风险信号(未触及任何与 revert 相关的高风险路径)。一个如实的提示:这会让发布同步 PR 的合并路径上不再有人工点击。这是 PR 的明确意图,也是发布负责人可以自己权衡的取舍——仅作为可见性提示,不是反对意见。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewBefore reading the diff, my independent take on "release PR needs two approvals but the author PAT can't approve its own PR": author the release PR with the workflow's installation token ( What I verified against the full workflow:
No correctness, security, or regression issues found. Two non-blocking notes:
Not verified: machine YAML parsing was not run in this review pass (the gate executes no code against PR content); the added step is byte-for-byte structurally identical to its sibling steps, and GitHub Actions will surface any syntax issue at the next release trigger. Testing (CI evidence)Unattended CI run — no PR code was built or executed by the reviewer; the evidence below is the PR's own CI on the reviewed commit, fetched via the API. At review time there were no failures; the ubuntu unit suite was still running. The macos/windows/integration skips are the classifier's expected shape for a workflow-only change ( Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行(取最新一次运行),省略 skipped,失败项排在最前。 The central claim — two bot approvals satisfying branch protection with no human — is behavioural and is not settleable by either sandboxed lane: 中文说明代码审查:在看 diff 之前,我对这个问题的独立方案就是本 PR 的做法——用 workflow 内置 installation token( 已对照完整 workflow 核实:权限授予是最小且正确的(内置 token 受 job permissions 约束,建 PR + 打 label 需要 PR write);changelog 提交在建 PR 之前推送,两个 approve 都在启用 auto-merge 之前完成,单次运行内不会有新 head 提交导致 review 被 dismiss;第二个 approve 步骤与现有 dev-bot 步骤结构、条件完全一致;重跑路径不变(已合并则跳过,已 open 则幂等)。未发现正确性、安全或回归问题。 两条非阻塞提示:1)PR 描述中"classifier/triage 视 github-actions[bot] 为可信"的论据略不精确——collaborator 权限查询对 bot 返回 未验证:本审查环节没有对 YAML 做机器解析(gate 不执行任何针对 PR 内容的代码);新增步骤与相邻步骤结构逐字节一致,若有语法问题会在下次发布触发时由 Actions 暴露。 测试证据:无人值守 CI 运行,审查方未构建或执行任何 PR 代码;上表为被审 commit 上 PR 自身 CI 的 API 实时状态。审查时无失败项,ubuntu 单测仍在运行。macos/windows/集成测试的 skipped 是 workflow-only 改动的预期分类结果; 核心行为主张(两个 bot approve 满足 branch protection、无需人工)无法由任何沙箱通道验证: — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 4/5 — clean, minimal, and well-evidenced; the only reservations are the verification limit inherent to a workflow-only change and two cosmetic nits already named above. Stepping back: the PR does exactly what I would have done — free both PAT identities by making the installation token the author, then let them supply the two approvals branch protection asks for. The problem is verified from #9054's actual review record, not asserted; the diff carries no hunk that isn't required; and the consumers that key on PR author are fork-gated or same-repo-keyed, so the author swap changes nothing else in the automation. The one thing that gives me pause is also the point of the PR: after this lands, the release-sync path has no human checkpoint at all. I'm comfortable with that as the maintainer's call — it's his documented intent, the removed click never carried review substance, and prior changes to this exact workflow (#6868, #7814, #8007) landed through this same pattern of bot review plus human sign-off. I'm approving because the change is verifiably sound at every point the diff and the API let me look, not because I ran out of objections; the behavioural claim itself proves out on the next stable release, and that is worth watching once. CI on the reviewed commit shows no failures so far, with the ubuntu unit suite still in flight — so approval is deferred until CI lands green on 中文说明回顾全局:这个 PR 的做法与我的独立方案完全一致——用 installation token 当作者,把两个 PAT 身份都空出来提供 branch protection 所需的两个 approve。问题由 #9054 的真实 review 记录证实,不是口头主张;diff 中没有任何多余的改动;按 PR author 分类的下游消费者要么只对 fork PR 生效、要么按同仓库 head 判断,所以作者切换不影响自动化链路的其他部分。唯一让我停顿一下的也正是 PR 的目的:合入之后发布同步路径将完全没有人工检查点。我接受这是维护者自己的决定——这是他明确写出的意图,被去掉的那次点击本来就不承载任何审查价值,而且此前对同一 workflow 的改动(#6868、#7814、#8007)都是通过"bot 审查 + 人工签署"的同一模式落地的。我给出 approve 是因为在 diff 和 API 能看到的每一个点上改动都可验证地正确,而不是因为没有反对意见了;行为主张本身要等下一次稳定发布才能证明,届时值得看一眼。 被审 commit 的 CI 目前无失败项,ubuntu 单测仍在运行——因此批准延迟到 CI 全绿后由 finalize 流程代为提交(见上方延迟批准标记)。 — Qwen Code · qwen3.8-max Reviewed at |
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
|
Updated the PR body to restore the current template Environment section. No code changes. CI, triage, and automatic review are still running. |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship — CI landed green after the review. ✅
|
Released in v0.21.12. |
What this PR does
Makes the automated release PR fully self-approving: creates it with the workflow installation token (author =
github-actions[bot]) instead ofCI_BOT_PAT, and adds a second approve step usingCI_BOT_PATnext to the existingCI_DEV_BOT_PATapprove step. Also grants the jobpull-requests: writeso the installation token can create/label the PR.Why it's needed
Today
finalize-release.ymlcreates the release PR withCI_BOT_PAT(author = qwen-code-ci-bot). GitHub forbids approving your own PR, so only the dev-bot approve step counts; the branch protection's second required approval had to be clicked by a human (see #9054, approved by dev-bot + yiliang114). With the author moved togithub-actions[bot], both PAT identities are free to approve, satisfying required_approving_review_count=2 with zero human action. Auto-merge (ci-bot) is unchanged.Reviewer Test Plan
How to verify
python3 -c "import yaml; yaml.safe_load(open('.github/workflows/finalize-release.yml'))").gh pr review --approveis idempotent per identity; the steps only run whenSHOULD_MERGE=true(PR open).Evidence (Before & After)
Tested on
(Workflow-only change; real verification happens on the next release run. YAML validated locally.)
Environment (optional)
Workflow-only change. Local validation used YAML parsing; live release behavior is pending the next stable release.
Risk & Scope
skip-changelogstill applied via pull-requests: write).Linked Issues
Follow-up to #9054 (release v0.21.11 PR needed a human approve).
中文说明
本 PR 做了什么
让发布同步 PR 完全自动通过:创建 PR 改用 workflow 内置 token(author 变为 github-actions[bot]),不再占用任一 PAT 身份;在现有 dev-bot approve 步骤旁新增 ci-bot approve 步骤;job 权限补
pull-requests: write以支持内置 token 建 PR/打 label。为什么需要
现在 finalize-release.yml 用 CI_BOT_PAT 建 PR(author=ci-bot),GitHub 禁止作者 approve 自己的 PR,所以只有 dev-bot 一个 approve 生效,branch protection 要求的第二个 approve 需要人点(#9054 就是 dev-bot + yiliang114)。author 换成 github-actions[bot] 后两个 PAT 都能 approve,required=2 自动满足,无需人工。auto-merge(ci-bot)不变。
Reviewer 测试计划
如何验证
gh pr review --approve同身份幂等;步骤仅在 PR open(SHOULD_MERGE=true)时执行。证据(Before & After)
测试环境
(仅 workflow 改动;真实验证在下次发布运行。YAML 本地已校验。)
环境(可选)
仅 workflow 改动;本地只校验 YAML 解析,真实发布行为等待下次稳定发布验证。
风险与范围
关联 Issue
#9054 的后续(v0.21.11 发布 PR 需要人工 approve)。