ci(release): 发版后给本版本 PR 自动留「Released in vX.Y.Z」评论

[deepcoldy]

背景 / 为什么

GitHub 原生侧栏那个「released in vX.Y.Z」徽标,判定用的是 PR 分支的原始 head commit 能否从 tag 回溯 —— 而 squash 合并会把 PR 压成一个全新 commit,原始 head commit 变成孤儿(即便 squash 出的新 commit 能从 tag 到达,GitHub 也不认)→ 用 squash 的 PR 永远不显示该徽标。

实测 v3.7.1 佐证:

PR	合并方式	原生徽标
#650 #631	merge commit	✅ 显示
#645 #646 #629	squash	❌ 不显示

(release notes 里能提到 #645 等,是 CI 从 commit message 的 (#N) 文本抓的,与徽标是两套独立机制。)

申晗希望保持 squash 的线性历史,又能在 PR 上看到「进了哪个版本」。原生二者互斥,故用发版后自动评论作为 squash 兼容的等效替代。

改了什么

发版后给本版本包含的每个 PR 留一条可见可点的时间线评论:

🚀 Released in [v3.7.1](release 链接)

实现(复用现有机制,不新增 API 扫描)

• PR 列表复用:直接取 changelog 步骤已算好的 $RAW(type==pr 行)去重,写到 released_prs.txt 交给新步骤——不再多打一次 /commits/{sha}/pulls
• 只在 stable(latest)评论:if: steps.dist_tag.outputs.tag == 'latest',与同 job 已有 3 处 guard 用法一致。canary/beta/rc/next 是灰度,若也评论会先刷 -canary 再刷正式版、既噪又误导,且对齐原生徽标只关心正式 Release 的语义
• fail-soft:npm + Release 此时已发布,评论失败绝不能让 job 失败 → continue-on-error: true + 单 PR 内部容错
• 幂等:workflow 重跑(如签名恢复 re-run)不重复刷——靠隐藏标记 <!-- released-in:vX.Y.Z --> 先查后发
• FD 3 读列表:用 while read <&3 … done 3< file 而非 stdin,避免循环内 gh 子进程吃掉后续 PR 行导致漏评论
• 纯直推(列表为空)自然 no-op
• 新增 pull-requests: write 权限(原 job 仅 contents: write)

实际验证

• python3 yaml.safe_load 解析通过;if guard 与同 job 已有 3 处 dist_tag == 'latest' 用法一致
• bash 端到端模拟(mock gh):PR 抽取去重 ✅ / 幂等跳过已评论的 PR ✅ / FD3 隔离——即便 mock 的 gh pr comment 尝试读 stdin 也无 LEAK、不漏 PR:

  PR #629: commented.
  PR #645: already has comment, skipping (idempotent).
  PR #650: commented.
  

• 去重样例:645 出现两次(merge-commit 多子 commit 场景)→ 收敛为一条

影响面

• 纯改 release.yml 的 release job,只在 stable tag-push 时多跑一步评论
• 不动 npm publish / Release 创建 / 桌面资产 / ci(release): 新增手动触发的 npm dist-tag 回滚 workflow #651 的 dist-tag 回滚 workflow
• 不涉及运行时代码,无跨平台/CLI/后端影响

⚠️ 生效范围:合入后下一个 stable 版本起自动评论;历史 PR 不追溯(可后续手动补一次性脚本,若需要)。