The fallback PR from one-click publish will inevitably fail pr-validation: the workflow doesn't generate devlog or CHANGELOG. | 一键发布的 fallback PR 必然过不了 pr-validation：workflow 不生成 devlog 和 CHANGELOG #481

Activity

1. ranxianglei commented on Oct 15, 2026

   

   ranxianglei

   on Oct 15, 2026

   OwnerAuthor

   More actions

   🤖 Powered by ework · qwen3.8-27b

   [bot] 🏷

   查重: 不重复。检索了 open+closed 的 issue 与 PR(关键词 fallback / devlog / changelog / release-manual / validation):本缺陷只有 #481 一条。#400 是通用发布线程(范围不同)、#474 修的是 Bump 步 lockfile 版本漂移(Bump exit 1,症状与机制均不同)。issue 里「来源 PR #480」成立。

   查证结论(bug 真实,且比描述更严重) —— 我没有只凭描述,逐行读了代码并实测了 CI:

   • 读 .github/workflows/release-manual.yml + scripts/ci/check-pr.sh:
     • workflow 的 Bump 步只改 package.json + package-lock.json;其 "Verify bump diff" 步还强制变更集恰好等于这两个文件 —— 结构上就装不下 devlog / CHANGELOG。
     • check-pr.sh 对版本变更要求三样:devlog/{branch}/REQ.md、WORKLOG.md、以及两个 CHANGELOG 各含 ### v{VER}。
     • 分支名 YYYY-MM-DD_release-v* 能过第 1 项检查,后三项必挂。
   • 实测 PR release v1.18.4 #480(v1.18.4)的 check-runs:pr-validation = failure,其余 e2e / build / test(22,24) / build-artifact 全绿 —— 唯一的红就是门禁,与 issue 一致。
   • 额外发现(请留意):我核对了当前 origin/master —— 没有 v1.18.4 的 changelog 条目、也没有 devlog/*_release-v1.18.4/ 目录,CHANGELOG 顶部仍是 v1.18.3。也就是说 v1.18.4 是「裸发」的,master 上没有它的发布记录。这与 issue 所说「release v1.18.4 #480 已由 agent 补全产物(commit c2e0020)」不符 —— 至少这些产物没有落到 master。

   层次判断:

   • 表面现象:fallback PR 三项红。
   • 根本原因:一键发布 workflow 从设计上只产「版本 bump」,不产 AGENTS.md §5.4.2 要求的发布产物(devlog + 双 CHANGELOG)。直推路径同样缺这三样,只是直推不走 pr-validation 所以没被拦 —— 但后果一样(master 落一个没有记录的发布 commit,v1.18.4 就是实例)。所以根因是「workflow 缺产物生成」,不是「fallback 分支特殊」。

   方案评估:

   • A(推荐):workflow 在发布 commit 里自生成产物。实现方案我已想好,确认即开修,一个 PR 闭环:
     1. 新增 "Prepare release bookkeeping" 步(pre-flight 之后、commit 之前):算出 RELEASE_REF=$(date -u +%F)_release-v$VER(把 stale 分支加时间戳后缀的判断前移,保证 devlog 目录名恒等于最终分支名);模板化生成 devlog/$RELEASE_REF/{REQ,WORKLOG}.md;用 git log --no-merges --pretty='- %s' ${LAST_TAG}..HEAD 生成 ### v$VER — … 条目,前置进 CHANGELOG.md(after # Changelog)与 CHANGELOG.zh-CN.md(after # 更新日志)。
     2. 把 NOTES / LAST_TAG 的计算提前并复用(PR body 与 changelog 共用一份,消重)。
     3. 改 "Verify bump diff" 期望集为:package.json、package-lock.json、CHANGELOG.md、CHANGELOG.zh-CN.md、devlog/$RELEASE_REF/{REQ,WORKLOG}.md。
     4. commit 步 git add 全部产物再提交。直推 + fallback 两条路径都带上产物 → 直推让 master 有完整记录,fallback 让 PR 过门禁。
     • 代价:自动生成的 changelog 是 commit subject 初稿(质量可接受,发版前可润色);zh-CN 文件里的条目暂为英文 subject(CI 无翻译能力,仅满足门禁,可人工润色)。
   • B(check-pr.sh 对 release 分支豁免):等于给所有 release PR 弱化门禁 —— 门禁的意义就是逼出产物,豁免=把问题藏起来,不推荐。
   • C(维持现状写进文档):把摩擦永久化;v1.18.3、v1.18.4 已连续两次踩坑且 v1.18.4 已裸发,不该接受为常态。

   八问(决策请求体例):

   1. 是什么问题:一键发布的 fallback PR 永远过不了 pr-validation —— workflow 只提交版本号,不提交门禁要求的 devlog 和 CHANGELOG。
   2. 什么原因导致:workflow 设计上只产版本 bump(Bump 步 + Verify 步强制只允许这两个文件),而 pr-validation 按 §5.4.2 强制要 devlog REQ/WORKLOG + 双 CHANGELOG 含新版本号;两套约定没对齐,且直推/fallback 两条路径都不生成产物。
   3. 影响范围与严重程度:
      • A:影响面=一键发布流程(纯 CI,无运行时改动);严重程度=消除「每次发布卡门禁 + master 缺记录」(v1.18.4 已实际裸发)。
      • B:影响面=所有 release PR 的门禁强度;严重程度=门禁被系统性弱化,后续任何 release 都能绕过产物要求。
      • C:影响面=发布体验;严重程度=持续摩擦 + master 记录缺口反复出现(v1.18.4 已是既成事实)。
   4. 怎么修(A 思路):把「生成发布产物」做成 workflow 的一个原子步骤,与 bump 一起进同一个发布 commit,两条落库路径都覆盖;同时放宽 Verify 步期望集以容纳新文件。
   5. 是否有回归(按选项):
      • A:低。纯 CI YAML 改动,无运行时/状态格式变化。需盯两点:① Verify 步期望集别写错导致误拦/误放;② stale 分支加时间戳后缀时 devlog 目录名必须跟随(否则又挂 devlog 检查)—— 靠前移命名逻辑解决。另见第 8 问的行为变更披露。
      • B:高。弱化门禁本身即一种语义回退(§5.4.2 的产物约束对 release 失效)。
      • C:无代码回归,但把既有缺陷固化为长期成本。
   6. 是否破坏缓存:不涉及(CI 无缓存/游标/去重键语义)。
   7. 是否改设计方向:A 不改架构,只是让 workflow 补齐它本该产出的产物、与 §5.4.2 对齐;数据流不变。
   8. 是否引入新配置 / 行为变更披露:不引入新 env/config。旧→新:① 发布 commit 内容:旧=仅 package.json+lock,新=+ devlog/{ref}/{REQ,WORKLOG}.md + 双 CHANGELOG 新条目;② changelog 质量:旧=人工手写,新=git log 自动初稿(可润色);③ zh-CN changelog 条目语言:旧=中文,新=英文 subject 占位(待人工润色)。

   选项对比:

   	能否根治	门禁强度	运行时风险	master 记录完整	工作量
   A(推荐)	✅ 两路径都覆盖	保持	无(纯 CI)	✅ 完整	中(改 1 个 workflow)
   B	❌ 只是放行	❌ 弱化	无	❌ 仍可能缺	小
   C	❌ 维持摩擦	保持	无	❌ 仍缺	极小(仅文档)

   请求拍板:确认走 A 我就开修(单 PR 闭环:workflow 生成产物 + Verify 步期望集 + 对应 devlog)。另:要不要我把已裸发的 v1.18.4 补一份 changelog + devlog(独立小 PR,或并入 A 的 PR)一并处理?你定方向,我立即执行。
2. ranxianglei

   changed the title [-]一键发布的 fallback PR 必然过不了 pr-validation：workflow 不生成 devlog 和 CHANGELOG[/-] [+]The fallback PR from one-click publish will inevitably fail pr-validation: the workflow doesn't generate devlog or CHANGELOG. | 一键发布的 fallback PR 必然过不了 pr-validation：workflow 不生成 devlog 和 CHANGELOG[/+] on Oct 16, 2026