ci(release): comment released-in version on merged PRs by yiliang114 · Pull Request #7814 · QwenLM/qwen-code

yiliang114 · 2026-07-27T07:03:53Z

What this PR does

When a stable release is published, the release finalization job now leaves a short comment on every PR that landed in that release, linking to the release tag. The comment carries a hidden marker so it can be detected later, and posting it is best-effort — any failure (a number that resolves to an issue rather than a PR, a rate-limited call) is logged as a warning and never blocks the release.

Why it's needed

Once a PR is merged, there is no easy way to look at that PR and tell which stable version shipped it. Release notes answer "version → PR", but contributors usually want the reverse: "my PR → which release". Tagging PRs with per-version labels does not scale (one label per release forever), so a timestamped bot comment on the PR timeline is the standard pattern used by projects like angular/babel/vue, and it keeps the label namespace clean.

Reviewer Test Plan

How to verify

The step only runs on real stable releases, so the lightest confirmation path is:

Trigger the finalization workflow manually on an already-shipped stable tag (e.g. v0.20.1) via the workflow_dispatch input tag = v0.20.1. The comment is marker-tagged and the merge-back PR is skipped when already merged, so re-running on a past tag is safe and idempotent.
Pick a few PRs from the v0.20.1 release notes and confirm a "Released in v0.20.1" comment now appears on each, posted by the CI bot.
Trigger the same dispatch again; the second run should log "already has a release comment; skipping" for every PR and post nothing new (marker dedup).
Inspect the run log for the new step: it prints "Found N PRs between v0.20.0 and v0.20.1", then one line per PR.

Evidence (Before & After)

N/A — non-UI change. The PR-timeline outcome is what the "How to verify" steps produce.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	N/A
🐧 Linux	⚠️

The bash enumeration logic was dry-run locally against real tags (v0.20.1..v0.21.0 resolved 137 PRs; the empty-range path exits 0 cleanly). Actual comment posting only happens inside the ubuntu-latest runner.

Environment (optional)

N/A — change is to a GitHub Actions workflow; no local runtime involved.

Risk & Scope

Main risk or tradeoff: On a large release (~150 PRs) the step issues ~300 API calls (one gh pr view + one gh pr comment per PR), well within the 5000/hr authenticated limit but visible in the run. Posting is best-effort with continue-on-error, so a partial failure never breaks the release.
Not validated / out of scope: Nightly and preview releases are intentionally excluded (finalization only handles stable tags). False-positive #NNN matches that resolve to issues rather than PRs are tolerated — gh pr comment fails on them and the step logs a warning and continues.
Breaking changes / migration notes: None. Purely additive step; no existing finalization behavior changes.

Linked Issues

None — opened per maintainer request.

中文说明

这个 PR 做什么

稳定版发布后，发布收尾任务会为该版本包含的每个 PR 留下一句简短评论，并附上 release tag 链接。评论带有一个隐藏 marker 以便后续识别；投递是 best-effort 的——任何失败（编号实为 issue 而非 PR、限流）只记为 warning，绝不阻塞发布。

为什么需要

PR 合并后，没有便捷的办法从 PR 反查它进了哪个稳定版本。Release notes 只回答「版本 → PR」，而贡献者通常要的是反方向「我的 PR → 哪个版本」。按版本打 label 不可持续（版本无限多），所以用带时间戳的 bot 评论记录在 PR timeline 上，是 angular/babel/vue 等项目的标准做法，也不污染 label 命名空间。

评审验证计划

如何验证

该 step 仅在真实稳定版发布时触发，最轻的验证路径是：

对已发布的稳定 tag（如 v0.20.1）用 workflow_dispatch 输入 tag = v0.20.1 手动触发收尾 workflow。评论带 marker，且回合 PR 在已合并时会被跳过，故对历史 tag 重跑是安全幂等的。
从 v0.20.1 的 release notes 里挑几个 PR，确认每个 PR 上都出现了由 CI bot 发的 "Released in v0.20.1" 评论。
再次触发同一 dispatch；第二次应为每个 PR 输出 "already has a release comment; skipping" 且不发新评论（marker 去重）。
查看新 step 的运行日志：先打印 "Found N PRs between v0.20.0 and v0.20.1"，随后每个 PR 一行。

证据（Before & After）

N/A —— 非 UI 改动。PR timeline 上的结果即「如何验证」步骤的产物。

测试平台

OS	状态
🍏 macOS	✅
🪟 Windows	N/A
🐧 Linux	⚠️

bash 枚举逻辑已在本地用真实 tag 干跑（v0.20.1..v0.21.0 解析出 137 个 PR；空范围路径干净退出 0）。实际评论投递只发生在 ubuntu-latest runner 内。

环境

N/A —— 改动为 GitHub Actions workflow，无本地运行时。

风险与范围

主要风险/取舍：大版本（约 150 PR）该 step 会发约 300 次 API 调用（每 PR 一次 gh pr view + 一次 gh pr comment），远低于认证 5000/小时限额，但在 run 中可见。投递为 best-effort，带 continue-on-error，部分失败绝不阻塞发布。
未覆盖/超出范围：nightly 与 preview 发布被有意排除（收尾只处理稳定 tag）。grep 误匹配到的 #NNN 若实为 issue 而非 PR 会被容忍——gh pr comment 会失败，step 记 warning 后继续。
破坏性变更/迁移说明：无。纯新增 step，不改变任何既有收尾行为。

关联 Issue

无——按 maintainer 要求开启。

After a stable release is published, comment on each merged PR in the release range with a link to the release tag, so contributors can find which version shipped their change directly from the PR timeline. Collects PR numbers from squash-merge commit subjects between the previous and current stable tags, posts a marker-tagged comment, and skips PRs that already carry the marker (re-run safety). Nightly and preview releases are out of scope, since finalize only handles stable tags.

qwen-code-ci-bot · 2026-07-27T07:04:32Z

🔄 Qwen Triage is running — watch live progress. Stage results will post in this thread as they complete.

🔄 Qwen Triage 正在运行 —— 查看实时进度。各阶段结果完成后会更新在本线程。

qwen-code-ci-bot · 2026-07-27T07:07:12Z

Thanks for the PR!

Template looks good ✓

Problem: This is a workflow improvement, not a bug fix — the gap is real and observable: once a PR is merged, there's no way to look at it and know which stable version shipped it. The PR notes it was opened per maintainer request, and the pattern (bot comment on PR timelines) is well-established in angular/babel/vue.

Direction: Aligned. This is squarely within release infrastructure, purely additive, and doesn't touch any existing finalization behavior. No direction concerns.

Size: Not applicable — no core module paths touched. Both changed files are CI workflow and its test.

Approach: The scope is tight — one new workflow step plus one test asserting its structure. Every edit serves the stated goal. No unrelated changes, no drive-by refactors. The marker-based dedup and continue-on-error are the right calls for idempotency and release safety.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓

问题：这是一个流程改进，不是 bug 修复——缺口是真实可观察的：PR 合并后，无法从 PR 页面得知它进了哪个稳定版本。PR 说明是按 maintainer 要求开启的，且 bot 评论模式在 angular/babel/vue 等项目中已是标准做法。

方向：对齐。完全属于发布基础设施范畴，纯新增，不改变任何既有收尾行为。无方向性顾虑。

规模：不适用——未触及核心模块路径。两个改动文件均为 CI workflow 及其测试。

方案：范围紧凑——一个新 workflow step 加一个结构断言测试。每处改动都服务于既定目标。无无关改动、无顺手重构。marker 去重和 continue-on-error 是幂等性和发布安全的正确选择。

进入代码审查 🔍

— Qwen Code · qwen3.8-max-preview

_{Reviewed at e6113d651e78ba9a6446fd79a01174e6eb40696e · re-run with @qwen-code /triage}

qwen-code-ci-bot · 2026-07-27T07:08:10Z

Code Review

Independent proposal: For "tell me which release shipped my PR", I'd add a post-release step that enumerates PRs between two tags via git log on squash-merge subjects, posts a marker-tagged comment on each, and makes the whole thing best-effort so it never blocks a release.

Comparison with the diff: The PR's approach matches this exactly. The implementation is clean:

The grep -oE '$#[0-9]+$$' pattern correctly targets only squash-merge trailers (the (#NNN) at the end of commit subjects), avoiding false positives from #NNN references elsewhere in commit messages. The test explicitly asserts this distinction.
Marker-based dedup () with a pre-post check via gh pr view --json comments makes re-runs idempotent.
continue-on-error: true plus per-PR || echo "::warning::..." ensures a single failure (e.g. a number that resolves to an issue) never blocks the release.
sort -un deduplicates PR numbers; || true on the grep pipeline handles empty ranges under pipefail.
The step is placed after release notes but before CHANGELOG regeneration — sensible ordering.

No critical blockers. No convention violations. The test follows the existing getStep pattern in the file and asserts the meaningful structural properties.

Testing

This is a CI workflow change with no user-visible runtime behavior — real-scenario tmux testing is N/A.

CI evidence from the PR's own checks on e6113d651e78ba9a6446fd79a01174e6eb40696e:

Check	Conclusion
Test (ubuntu-latest, Node 22.x)	✅ success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	✅ success
Classify PR	✅ success
precheck-pr / precheck	✅ success
label	✅ success
review-pr	✅ success
Test (macos-latest, Node 22.x)	⏭️ skipped
Test (windows-latest, Node 22.x)	⏭️ skipped
Integration Tests (CLI, No Sandbox)	⏭️ skipped

All completed checks passed. macOS/Windows tests and integration tests were skipped (expected for a CI-only change that doesn't touch runtime code). No failures.

中文说明

代码审查

独立方案： 对于"告诉我 PR 进了哪个版本"，我会在发布后添加一个 step，通过 git log 从 squash-merge 主题中枚举两个 tag 之间的 PR，对每个 PR 发一条带 marker 的评论，并将整个流程设为 best-effort 以免阻塞发布。

与 diff 对比： PR 的方案与此完全一致。实现干净：

grep -oE '$#[0-9]+$$' 只匹配 squash-merge 尾部标记，避免误匹配提交消息中其他位置的 #NNN。测试明确断言了这一区分。
基于 marker 的去重（）加发前检查确保重跑幂等。
continue-on-error: true 加逐 PR 的 || echo "::warning::..." 确保单个失败不阻塞发布。
sort -un 去重；grep 管道上的 || true 处理 pipefail 下的空范围。
step 放在 release notes 之后、CHANGELOG 重新生成之前——顺序合理。

无关键阻塞项。无规范违反。测试遵循文件中已有的 getStep 模式。

测试

这是 CI workflow 改动，无用户可见的运行时行为——tmux 真实场景测试不适用。

CI 证据来自 PR 自身在 e6113d651e78ba9a6446fd79a01174e6eb40696e 上的检查：所有已完成的检查均通过。macOS/Windows 测试和集成测试被跳过（对纯 CI 改动属预期）。无失败。

— Qwen Code · qwen3.8-max-preview

_{Reviewed at e6113d651e78ba9a6446fd79a01174e6eb40696e · re-run with @qwen-code /triage}

qwen-code-ci-bot · 2026-07-27T07:09:03Z

Confidence: 5/5 — clean across every stage; would merge without hesitation.

This is exactly the kind of PR that's easy to evaluate: small, focused, solves a real operational gap, and the implementation matches what I'd write independently. The squash-merge trailer parsing is precise, the idempotency story is solid (marker dedup + continue-on-error), and the test asserts the right structural properties without over-specifying.

The author dry-ran the enumeration logic against real tags (137 PRs resolved for v0.20.1..v0.21.0), which is the right level of local validation for a workflow step that only fires on real releases. The ~300 API calls for a large release are well within rate limits, and the best-effort design means a partial failure degrades gracefully.

Nothing to second-guess here. Ships the feature cleanly.

中文说明

置信度：5/5 —— 每个阶段都干净；毫不犹豫可以合并。

这是一个容易评估的 PR：小、聚焦、解决真实的运营缺口，实现与我的独立方案一致。squash-merge 尾部解析精确，幂等方案扎实（marker 去重 + continue-on-error），测试断言了正确的结构属性而不过度指定。

作者用真实 tag 干跑了枚举逻辑（v0.20.1..v0.21.0 解析出 137 个 PR），对于只在真实发布时触发的 workflow step 来说，这是恰当的本地验证级别。大版本约 300 次 API 调用远在限额内，best-effort 设计意味着部分失败会优雅降级。

没有需要犹豫的地方。干净地交付了功能。

— Qwen Code · qwen3.8-max-preview

_{Reviewed at e6113d651e78ba9a6446fd79a01174e6eb40696e · re-run with @qwen-code /triage}

qwen-code-ci-bot

Reviewed. Suggestions are inline.

中文说明

已审查。建议见行内评论。

— qwen3.7-max via Qwen Code /review

qwen-code-ci-bot

LGTM, looks ready to ship — CI landed green after the review. ✅

qwen-code-ci-bot

Reviewed. Suggestions are inline.

中文说明

已审查。建议见行内评论。

— qwen3.7-max via Qwen Code /review

qwen-code-ci-bot

⚠️ Downgraded from Approve to Comment: CI still running. Reviewed.

中文说明

⚠️ 已从批准降级为评论：CI still running。已审查。

— qwen3.7-max via Qwen Code /review

yiliang114 · 2026-07-27T13:27:53Z

@qwen-code /triage

qwen-code-ci-bot · 2026-07-27T13:36:30Z

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

qwen-code-ci-bot · 2026-07-27T13:37:17Z

Triage re-run completed without a new review.

⚠️ The bot has no review of its own on e6113d651e78ba9a6446fd79a01174e6eb40696e. If this re-run was meant to approve, it did not — an approval left by another account is a separate vote and does not count as the bot's own.

The stage comments above were updated with the latest result. View workflow run.

yiliang114 · 2026-07-27T14:45:14Z

@qwen-code /triage

qwen-code-ci-bot

LGTM, looks ready to ship. ✅

doudouOUC

No issues found. LGTM! ✅

中文说明

未发现问题。LGTM！✅

— qwen3.7-max via Qwen Code /review

yiliang114 added the skip-changelog Exclude from release notes label Jul 27, 2026

qwen-code-ci-bot reviewed Jul 27, 2026

View reviewed changes

Comment thread .github/workflows/finalize-release.yml

Comment thread .github/workflows/finalize-release.yml Outdated

qwen-code-ci-bot previously approved these changes Jul 27, 2026

View reviewed changes

fix(ci): narrow release PR extraction

e4b2c01

yiliang114 dismissed qwen-code-ci-bot’s stale review via e4b2c01 July 27, 2026 10:46

qwen-code-ci-bot reviewed Jul 27, 2026

View reviewed changes

Comment thread scripts/tests/ai-release-notes-workflow.test.js

Comment thread scripts/tests/ai-release-notes-workflow.test.js

test(ci): cover release comment safety checks

e6113d6

qwen-code-ci-bot reviewed Jul 27, 2026

View reviewed changes

wenshao approved these changes Jul 27, 2026

View reviewed changes

qwen-code-ci-bot approved these changes Jul 27, 2026

View reviewed changes

yiliang114 added this pull request to the merge queue Jul 27, 2026

Merged via the queue into QwenLM:main with commit ad22524 Jul 27, 2026
61 checks passed

doudouOUC approved these changes Jul 27, 2026

View reviewed changes

qwen-code-ci-bot mentioned this pull request Aug 13, 2026

fix(ci): let both bot PATs approve the release PR, no human needed #9056

Merged

Uh oh!

Conversation

yiliang114 commented Jul 27, 2026

What this PR does

Why it's needed

Reviewer Test Plan

How to verify

Evidence (Before & After)

Tested on

Environment (optional)

Risk & Scope

Linked Issues

这个 PR 做什么

为什么需要

评审验证计划

如何验证

证据（Before & After）

测试平台

环境

风险与范围

关联 Issue

Uh oh!

qwen-code-ci-bot commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qwen-code-ci-bot commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qwen-code-ci-bot commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review

Testing

代码审查

测试

Uh oh!

qwen-code-ci-bot commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qwen-code-ci-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

qwen-code-ci-bot left a comment

Choose a reason for hiding this comment

Uh oh!

qwen-code-ci-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

qwen-code-ci-bot left a comment

Choose a reason for hiding this comment

Uh oh!

yiliang114 commented Jul 27, 2026

Uh oh!

qwen-code-ci-bot commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qwen-code-ci-bot commented Jul 27, 2026

Uh oh!

yiliang114 commented Jul 27, 2026

Uh oh!

qwen-code-ci-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

doudouOUC left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

qwen-code-ci-bot commented Jul 27, 2026 •

edited

Loading

qwen-code-ci-bot commented Jul 27, 2026 •

edited

Loading

qwen-code-ci-bot commented Jul 27, 2026 •

edited

Loading

qwen-code-ci-bot commented Jul 27, 2026 •

edited

Loading

qwen-code-ci-bot commented Jul 27, 2026 •

edited

Loading