ci(release): exclude-paths 让纯文档改动不再 mint 版本(附 RP 匹配语义的三条坑) - #138
Merged
Merged
Conversation
实测起因:#136 是**两个 `docs(release):` 提交、零代码改动**,合并 25 秒后 RP 就开出了 #137 `chore(main): release 2.2.6`,CHANGELOG 段是 3 条 `### Documentation`(它把 PR 的两条 真实提交**和 #136 的 merge commit 各算了一条**)。按自动路径的规矩,这一条版本要人再补 5 类 手工同步位 + 手工补跑镜像(tag 不级联那一条),而用户拿到的东西一个字节没变。这税不划算。 配置:`packages["."].exclude-paths = ["docs", "tests"]`。放在**包内那一层**而不是顶层同名键 —— RP 的 `CommitExclude` 构造器吃 `Record<packagePath, {excludePaths}>`,包内一定生效;顶层是否 被合并进包配置我没在源码里读到确证,写在那儿就是"看起来配了、其实没生效"那个老形状。 三个坑是读 `src/util/commit-exclude.ts` 确认的(匹配式 `file.startsWith(entry + "/")`, **不是 glob**),都落成了闸 `test_exclude_paths_entries_are_all_actionable`: 1. `docs/**` 这种写法永不命中,只能用裸目录名(RP 自己的测试用的就是 `['pkg3','pkg1']`); 2. 仓库根上的单个文件排不掉(那个 `+"/"` 让 `README.md`/`CHANGELOG.md`/ `release-please-config.json` 都做不成条目)—— 所以"只改发版配置"的提交仍会 mint 版本, 今天 #137 就是这么留下的,本条提交也是; 3. 条目写成 `.` 会把**所有**提交排掉,RP 从此不报错也不发版。 另加两条边界:排掉的目录里不许有 RP 要写的版本位,也不许有随包分发的代码(`app/`)。 顺带修两处已经数不对的话:§5 写"仓库内跟踪的 9 处",`_site_versions()` 今天是 **11** 行 (含 `scripts/installer/version.json` 那个装配中间物与本文 §1 那句散文);§1 里"第 10 处" 的序号也漂了,改成"今天这张表 11 行,它是最后收进来的一行"。 验证: - 变异复验 5 种写法(`docs/**` / `.` / 不存在的目录 / 清空列表 / 覆盖 `app/`)**全部 rc=1**, 还原配置后 `test_version_consistency.py` + `test_release_readiness_gate.py` 13 passed; `ruff check` + `format --check` 通过。 - 5 个发版链路测试文件合计 **31 passed**(版本位 9 + 发布条件闸 4 + DCO 豁免 4 + 缓存预算 2 + 性能门禁 12)。 - `check_release_readiness.py --root .` 仍判"发版条件满足"(11 处 = 2.2.5,8 条判据 PASS)。 - 合完之后要看一眼 #137:按上面第 2 条,它不会自动关,内容会从"3 条 Documentation"变成 带这条 config 改动 —— 关不关是 Release 侧动作,交回 owner。 Signed-off-by: ReSerendipity <zengyangc@outlook.com>
This was referenced Sep 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
起因(实测,不是推测)
#136 是两个
docs(release):提交、零代码改动。合并 25 秒后 release-please 就开出了 #137chore(main): release 2.2.6,它的 CHANGELOG 段长这样:也就是说:一条纯文档改动 = 一个可发布版本 = 我要再手工补 5 类同步位 + 手工补跑镜像(#136 那条 PR 自己记录的 tag 不级联问题),而用户拿到的产物一个字节都没变。这税不划算,而且 RP 还把 merge commit 与真实提交重复计数。
改了什么
release-please-config.json:packages["."].exclude-paths = ["docs", "tests"]。放在包内那一层而不是顶层同名键:
CommitExclude的入参类型是Record<packagePath, {excludePaths}>,包内一定是生效路径;顶层是否被合并进包配置,我没在源码里读到确证 —— 写在顶层就会变成"看起来配了、其实没生效",那是本仓踩过的老形状(v2.2.2 的 RP 空转)。这个字段不是 glob(读
src/util/commit-exclude.ts确认,匹配式file.startsWith(entry + "/");RP 自己的测试夹具用的是['pkg3','pkg1'])。由此三条,都落成了闸test_exclude_paths_entries_are_all_actionable:docs/**永不命中 —— 只能用裸目录名docs。+"/"让README.md、CHANGELOG.md、release-please-config.json都做不成条目。推论要讲清楚:"只改发版配置"这一类提交仍然会 mint 一个版本,本条 PR 就是活例子,chore(main): release 2.2.6 #137 也不会因为本 PR 合入而自动关(见"合并后要看的")。.会把所有提交排掉,RP 从此一声不响再也不发版(不报错,正是"永远绿却什么都不做")。另加两条边界断言:被排的目录里不许有 RP 要写的版本位,也不许有随包分发的代码(
pyproject的packages.find where=['app'])—— 这两条是真会漏东西的地方。docs/release-governance.md:§1 的"走这条路必须知道 N 件事"加到第 5 条(发版范围 + 上面三个坑 + 闸名);顺手修两处已经数不对的话 —— §5 写"仓库内跟踪的 9 处",_site_versions()今天是 11 行(含scripts/installer/version.json那个装配中间物与 §1 那句散文);§1 里"第 10 处"的序号也漂了,改成按实际行数说。验证(数字都是跑出来的)
rc=1):docs/**、.、不存在的目录、清空列表、覆盖app/。还原配置后test_version_consistency.py+test_release_readiness_gate.py= 13 passed。ruff check/ruff format --check通过。scripts/check_release_readiness.py --root .仍判"发版条件满足":11 处版本位 = 2.2.5,8 条判据全 PASS。合并后要看的(我不替 RP 断言)
本 PR 合进 main 之后 #137 有两种可能,取决于 RP 会不会在"候选提交为空"时自己关 PR —— 这一点我没找到确证,所以不当结论:
ci(release):提交"继续开着:符合上面第 2 条的推论。这种情况关不关是 Release 侧动作,我停手交回 owner。没做什么
.github/**、benchmarks/**、scripts/**的排除:本仓刚发的 v2.2.5 内容正是发布链路(.github+scripts+tests),把 CI 侧也排掉会跟你已经认可过的"发布链路本身可以是一个版本"打架。要不要一起排是口味问题,等你定。