ci: move release-note classifier from per-PR workflow to release-time batch - #7339
Conversation
|
Thanks for the PR! Template looks good ✓ Problem: this is a Direction: aligned — moving classification to release time is strictly simpler. Follow-up to #7251 which introduced the classifier. No CHANGELOG reference needed for CI infra. Size: not applicable — no core paths touched. All 4 changed files are in Approach: the scope is right. Delete the standalone workflow, convert the classifier to batch mode (stdin JSON array), add one step to the release publish job. The previous review's Moving on to code review. 🔍 中文说明感谢贡献! 模板完整 ✓ 问题:这是一个 方向:对齐——将分类移到发布时严格更简单。是 #7251(引入分类器)的后续优化。CI 基础设施不需要 CHANGELOG 引用。 规模:不适用——未触及核心路径。全部 4 个变更文件都在 方案:范围合理。删除独立工作流,将分类器转为批量模式(stdin JSON 数组),在 release publish job 中添加一个步骤。上次审查发现的 进入代码审查 🔍 — Qwen Code · qwen3.7-max Reviewed at |
Code ReviewIndependent proposal: given the goal "move release-note classification from per-PR to release-time batch", I would: (1) delete the standalone workflow, (2) convert the classifier to accept a JSON array of PRs on stdin, (3) add a step in the release publish job that enumerates commits since the previous tag via Comparison: the PR matches this approach exactly. No simpler path missed. The The release.yml step is well-structured: The previous review's No critical blockers. No AGENTS.md violations. TestingThis is a CI-only change (no CLI behavior), so real-scenario testing means running the classifier test suite and validating the workflow YAML structure. All 3 tests pass. Workflow YAML parses correctly with the expected step configuration. The standalone workflow is confirmed deleted. The changelog exclusion config is intact. 中文说明代码审查独立方案: 给定目标"将 release-note 分类从逐 PR 移到发布时批处理",我会:(1) 删除独立工作流,(2) 将分类器转为接受 stdin JSON 数组,(3) 在 release publish job 中添加步骤,用 对比: PR 与此方案完全一致。没有遗漏更简路径。
release.yml 步骤结构良好: 上次审查的 无关键阻塞。无 AGENTS.md 违规。 测试这是纯 CI 变更(无 CLI 行为),因此真实场景测试意味着运行分类器测试套件并验证工作流 YAML 结构。全部 3 个测试通过。工作流 YAML 正确解析。独立工作流已确认删除。Changelog 排除配置完好。 — Qwen Code · qwen3.7-max Reviewed at |
|
Confidence: 5/5 — clean across every stage; the previous review's Going back to my independent proposal: the PR matches it exactly. Delete the per-PR workflow, batch the classifier, wire it into the release job. No simpler path exists — this is the minimal version. The code reads well. The classification logic ( The previous review found a real bug ( Tests cover the three things that matter: classification logic, workflow wiring, and batch error handling. All pass. If I had to maintain this in six months, I'd thank the author — one batch step at release time is much easier to reason about than a per-PR workflow with label lifecycle management and loop prevention. 中文说明置信度:5/5 — 每个阶段都干净;上次审查的 回到我的独立方案:PR 与之完全一致。删除逐 PR 工作流,批处理分类器,接入 release job。不存在更简路径——这就是最小版本。 代码可读性好。分类逻辑( 上次审查发现了一个真实 bug( 测试覆盖了三件重要的事:分类逻辑、工作流接线、批量错误处理。全部通过。 如果六个月后我要维护这个,我会感谢作者——发布时一个批量步骤比带标签生命周期管理和防循环的逐 PR 工作流容易推理得多。 — Qwen Code · qwen3.7-max Reviewed at |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
The merged: search qualifier in the release.yml batch step uses tag names (merged:${PREVIOUS_RELEASE_TAG}..${RELEASE_TAG}), but GitHub only accepts ISO date ranges there — tag names silently return zero results, so the batch step won't label any PRs. See my detailed comment above for verification and suggested fixes. Everything else looks great — this should be a quick fix. 🙏
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. |
|
The review issue is addressed at Verified locally on the PR head:
No additional commit was pushed from this patrol because the remote branch already contained the fix. Latest PR checks are still running. |
|
Verification update:
|
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed. Suggestions are inline.
— qwen3.7-max via Qwen Code /review
ReviewMoving classification out of I validated the two assumptions this design rests on against real data:
So the logic is sound. My concerns are all about failure being invisible. 1. A broken
|
doudouOUC
left a comment
There was a problem hiding this comment.
— qwen3.7-max via Qwen Code /review
|
Qwen Code review timed out. Qwen review timed out after 300 seconds (of the 180-minute budget). For large PRs, retry with a longer timeout by commenting: |
Code Review — 将 release-note 分类从逐-PR 工作流迁移到发布时批处理概述把 验证结论(已在本地实测 ✅)
优点
建议 / 风险(均为非阻塞)
结论改动正确、职责清晰、测试与 fail-open 设计到位,端到端编排我已实测通过。LGTM,上面几点均为可选优化/知悉项,其中第 1、2 点建议关注。 |
doudouOUC
left a comment
There was a problem hiding this comment.
— qwen3.7-max via Qwen Code /review
|
@qwen-code /triage |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
|
Released in v0.20.1. |
What this PR does
Moves the automatic release-note classification from a standalone per-PR workflow (triggered on every PR event) into the release workflow itself. The classifier now runs once at release time as a batch step before
gh release create --generate-notes, labeling qualifying internal CI PRs withskip-changelog-autoso they are excluded from generated release notes.Why it is needed
The previous approach ran a classification workflow on every PR open/synchronize/label event, adding CI noise and requiring label lifecycle management (add/remove/loop prevention). The classification only matters at release time, so running it once in the release workflow is simpler and sufficient.
Reviewer Test Plan
How to verify
Run the classifier test suite:
node --test .github/scripts/classify-release-notes.test.mjs— all 3 tests should pass, including the new batch-mode integration test. Confirm that.github/workflows/classify-release-notes.ymlis deleted and that.github/workflows/release.ymlcontains the new "Auto-label internal CI PRs" step before "Create GitHub Release and Tag".Evidence (Before & After)
Before: a standalone
classify-release-notes.ymlworkflow triggered on 7 PR event types, with label add/remove logic and loop prevention.After: no standalone workflow; a single batch step in the release publish job lists merged PRs in the release range and labels qualifying ones.
Tested on
Environment (optional)
Node.js 22, local macOS workspace.
Risk & Scope
skip-changelog-autolabel during normal development. This is acceptable since the label only affects release notes generation.dry_run=true; the non-dry-run label mutation remains intentionally unexecuted.Linked Issues
Follow-up to #7251.
中文说明
本 PR 做了什么
将自动 release note 分类从独立的逐 PR 工作流(每次 PR 事件都触发)移入 release 工作流本身。分类器现在在发布时作为批量步骤运行一次,在
gh release create --generate-notes之前,为符合条件的内部 CI PR 添加skip-changelog-auto标签,使其从生成的 release note 中排除。为什么需要
之前的方案在每个 PR 的 open/synchronize/label 事件上都运行分类工作流,增加了 CI 噪音并需要标签生命周期管理(添加/移除/防循环)。分类只在发布时有意义,因此在 release 工作流中运行一次更简单且足够。
Reviewer 测试计划
如何验证
运行分类器测试套件:
node --test .github/scripts/classify-release-notes.test.mjs——全部 3 个测试应通过,包括新的批量模式集成测试。确认.github/workflows/classify-release-notes.yml已删除,且.github/workflows/release.yml在 "Create GitHub Release and Tag" 之前包含新的 "Auto-label internal CI PRs" 步骤。证据(Before & After)
Before:独立的
classify-release-notes.yml工作流在 7 种 PR 事件类型上触发,包含标签添加/移除逻辑和防循环机制。After:无独立工作流;release publish job 中一个批量步骤列出发布范围内已合并的 PR 并为符合条件的添加标签。
测试平台
环境(可选)
Node.js 22,本地 macOS 工作区。
风险与范围
skip-changelog-auto标签。这是可接受的,因为该标签只影响 release note 生成。dry_run=true通过;非 dry-run 的标签写入按预期未执行。关联 Issue
#7251 的后续优化。