Skip to content

docs(release): release PR 上没有 CI 检查这件事必须写下来（并纠正我在 #123 里的假设） #128

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ReSerendipity merged 1 commit into from
Sep 22, 2026
Merged

docs(release): release PR 上没有 CI 检查这件事必须写下来（并纠正我在 #123 里的假设） #128

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions docs/release-governance.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,15 @@
2. 手工：`git tag -a` + `gh release create`（v2.2.2/v2.2.3 走的就是这条）。
手工发版之后 RP 会在下一条 release PR 里把版本号再抬一格（它按 manifest 算），
所以手工发完要把 `.release-please-manifest.json` 一起抬到刚发的版本，否则两边在版本号上互踩。
> **走第 1 条时，release PR 上看不到任何 CI 检查**（实测 #120：`gh pr checks 120` 是空的）。
> 原因是 GitHub 的固定行为：由 `GITHUB_TOKEN` 产生的提交不再级联触发 workflow，
> 而 release PR 的提交正是 bot 用 `GITHUB_TOKEN` 推的。
> 后果很具体：§1 上面列的那些**手工同步位**在 release PR 上不会变红 ——
> `test_all_version_sites_agree` 要到合并进 main 之后才红，那时 Release 已经发出去了。
> 所以合 release PR 之前**必须本地跑**：`.venv/Scripts/python.exe -m pytest tests/test_version_consistency.py`
> （外加 §2 第 1–2 步的手工位补齐）。要把它变成机器闸，就得给 release PR 配一个
> 由 `workflow_dispatch`/`push` 触发、能对 release 分支的 head SHA 报 commit status 的作业 ——
> 那是权限决策，不在本文档的"现状"里。
历史上 `release-please.yml` 曾是**结构性空转**（`skip-github-pull-request: true` + 缺
config/manifest + 5 个 v4 不认的入参 → 每次 main push 输出 `found 0 possible releases` 后绿，
v2.2.2 因此三次绿 run 都没 Release）；已修，现在它真的会开 PR。挂在它下面的
Expand Down
Loading