fix(ci): record cd-cua-driver.yml's shipped size in the workflow size baseline - #9823
Closed
wenshao wants to merge 1 commit into
Closed
fix(ci): record cd-cua-driver.yml's shipped size in the workflow size baseline#9823wenshao wants to merge 1 commit into
wenshao wants to merge 1 commit into
Conversation
… baseline Second instance of the shape #9747 fixed, in a different file. #9587 grew `cd-cua-driver.yml` from 29715 to 42519 bytes and did not move the manifest entry with it — 12804 bytes over, against a 4096-byte allowance — so the ratchet fails on `main` itself. The step it fails is `Check workflow file size`, number 7 of the `Test` job and ahead of `Install dependencies`, and a failure there skips every step after it. Any PR whose merge ref contains that commit therefore reports a red `Test` lane having run no tests at all, over a workflow file it never touched. Measured on two PRs from different authors, both failing at step 7 and at no other, while a PR still based on an earlier merge ref stays green. The growth is real — a versioned Computer Use SDK landed in that workflow — so the number moves rather than the file, and the ratchet resumes measuring drift from what is actually there. Nothing else in the manifest moves: all 52 workflow files have an entry, 48 match byte-for-byte, and the three remaining drifts are inside the allowance, which is what the allowance is for.
Collaborator
Collaborator
|
Thanks for the PR! Template looks good ✓ Problem: real, and independently verified. On Direction: aligned — this is the remedy the gate's own error message prescribes ("if the growth is real, update .github/workflows/.size-baseline in this PR and say why"), and it unblocks every PR's CI. Same shape as the already-merged #9747. Size: not applicable — one manifest line, no core paths. Approach: the minimal possible change. The alternatives are worse and the PR says why: trimming Risk: no elevated risk signals. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：真实存在，且已独立核实。 方向：对齐——这正是门禁自身报错信息开出的药方（"如果增长是真实的，在本 PR 里更新 .github/workflows/.size-baseline 并说明原因"），并且解开了所有 PR 的 CI。与已合入的 #9747 同形。 规模：不适用——一行清单数据，未触及核心路径。 方案：最小改动。其他替代方案更差，PR 里也解释了原因：裁掉 风险：无升级风险信号。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
|
Code review — no findings. My independent take before reading the diff was identical to what the PR does: the gate's error message itself prescribes updating the entry to the shipped size, and there is no simpler alternative (trimming CI evidence — quoted from the PR's own check-runs on the reviewed commit via the API; I did not build or run any PR code. The decisive lane is No behavioural claim needs a sandboxed lane here — the change is a byte-count constant, and the ubuntu Test job plus the vitest mirror pin it directly (without this diff the mirror is red; that is what is happening on
中文说明代码审查——无发现。我在看 diff 之前的独立方案与 PR 做法完全一致：门禁报错信息本身就开出了"把条目更新为落库大小"的药方，也没有更简的替代（裁 测试证据——引自该 commit 自身的 CI check（经 API 获取）；未构建或运行任何 PR 代码。决定性通道是 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
|
Confidence: 5/5 — clean across every stage; would merge without hesitation. This is the platonic ideal of a minimal fix. One stale number is turning every PR's Test lane red at step 7 before a single test runs, the fix is exactly the one line the gate's own error message prescribes, and I verified every factual claim in the description independently: the sizes on disk, the two unrelated PRs dying at that exact step and no other, the cause (#9587 landing after #9747), and the rest of the manifest staying honest. If I have to maintain this in six months, there is nothing to maintain — it is a number that matches reality again. The one genuine thought the PR leaves behind is the author's own: this is the second time the manifest was left behind, which is a signal about the mechanism (the ratchet catches the growing PR's author only if they remember to update the manifest in the same PR — #9587's author didn't, and every PR after it paid). Worth a follow-up issue on making the gate fail the PR that does the growing; explicitly out of scope here, and correctly so. Approval is deferred only because the decisive CI lane is still in flight: approval will land automatically once every check on the reviewed commit completes green, via the marker below. 中文说明信心：5/5——每个阶段都干净；毫不犹豫可合。 这是最小修复的范本。一个过期的数字让所有 PR 的 Test 通道在第 7 步就红掉、一个测试都没跑，而修复恰好就是门禁自身报错信息开出的那一行；描述里的每一项事实我都独立核实过：磁盘上的大小、两个不相关 PR 恰好挂在该步且不挂在其它步、成因（#9587 在 #9747 之后合入）、以及清单其余部分仍然准确。若六个月后维护它——无物可维护，只是一个重新符合现实的数字。 PR 留下的唯一真正思考是作者自己点出的：这是清单第二次被落下，说明机制本身有信号（棘轮只有在增长的 PR 作者记得同 PR 更新清单时才拦得住——#9587 的作者没有，之后所有 PR 为之买单）。值得开一个跟进 issue 讨论让门禁直接拦下制造增长的那个 PR；明确不在本 PR 范围内，且理应如此。 批准仅因决定性 CI 通道仍在运行而暂缓：审阅的 commit 上所有检查转绿后，将凭下方标记自动落批准。 — Qwen Code · qwen3.8-max Reviewed at |
Contributor
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. |
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
2 participants
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.
What this PR does
Corrects one number in
.github/workflows/.size-baseline: the entry forcd-cua-driver.ymlbecomes 42519, the size of the file that is actually on disk, replacing the 29715 it was left at.Why it's needed
This is the second instance of the shape #9747 fixed, in a different file. #9587 grew
cd-cua-driver.ymlfrom 29715 to 42519 bytes — a versioned Computer Use SDK and its release pipeline — and did not move the manifest entry with it. That is 12804 bytes over an allowance of 4096, so the growth ratchet fails onmainitself.The step it fails is
Check workflow file size, number 7 of theTestjob and ahead ofInstall dependencies, and a failure there skips every step after it. A PR whose merge ref contains that commit therefore shows a redTestlane that ran no tests at all, over a workflow file the PR never touched. Two PRs from different authors were measured failing at step 7 and at no other, while a PR still based on an earlier merge ref stays green — which is what places the cause.The growth is real, so the number moves rather than the file, and the ratchet resumes measuring drift from what is actually there.
Reviewer Test Plan
How to verify
On
main, both the shell gate and its vitest mirror fail; with this one-line change, both pass.Restoring the old number turns the mirror red again, so the single line is what the result hangs on.
The rest of the manifest is accurate and stays untouched: all 52 workflow files have an entry, 48 match their file byte-for-byte, and the three remaining drifts (
qwen-autofix-fork-signal.yml+1147,qwen-autofix.yml+827,qwen-code-pr-review.yml+146) are inside the allowance, which is what the allowance is for.Evidence (Before & After)
N/A — no user-visible surface; the before/after is the command output above.
Tested on
Environment (optional)
macOS; the gate is a byte count over files in the repo, so it has no platform-dependent behaviour. CI covers the Linux lane.
Risk & Scope
cd-cua-driver.ymlshould be smaller than 42519, and whether the ratchet wants a rule that fails the PR doing the growing rather than the next PR to merge — this is the second time the manifest has been left behind, which is a signal about the mechanism, not about either file.Linked Issues
Follows up #9747. Caused by #9587.
中文说明
本 PR 做了什么
修正
.github/workflows/.size-baseline里的一个数字：cd-cua-driver.yml的条目改为 42519，即磁盘上文件的真实大小，替换掉停留在那里的 29715。为什么需要
这是 #9747 修过的同一类问题第二次发生，换了个文件。#9587 把
cd-cua-driver.yml从 29715 涨到 42519 字节（版本化的 Computer Use SDK 及其发布流水线），却没有同步移动清单条目。超出 4096 允差 12804 字节，于是增长棘轮在main自己身上就失败。它失败的那一步是
Check workflow file size，Testjob 的第 7 步，排在Install dependencies之前，而该步失败会跳过其后的每一步。于是任何 merge ref 含该 commit 的 PR，都会看到一条红着的Test通道，而它一个测试都没跑，起因还是一个该 PR 从未碰过的 workflow 文件。实测两个来自不同作者的 PR 都恰好挂在第 7 步、且不挂在其它任何一步；而 merge ref 更早的 PR 仍然是绿的——这就定住了因果。增长是真实的，所以要动的是数字而不是文件；棘轮从真实存在的那个大小重新开始度量漂移。
评审验证计划
见上方英文正文的命令与输出。把旧数字改回去，镜像测试会重新变红——说明结果就悬在这一行上。清单其余部分准确、不做改动：52 个 workflow 文件都有条目，48 个逐字节相符，剩余三处漂移都在允差之内。
证据（前后对比）
N/A —— 没有用户可见界面；前后对比就是上面的命令输出。
风险与范围
cd-cua-driver.yml是否应当小于 42519；以及棘轮是否需要一条"让制造增长的那个 PR 失败、而不是让下一个合并的 PR 失败"的规则——清单被落下已经是第二次了，这是关于机制的信号，而不是关于这两个文件中的任何一个。关联 Issue
跟进 #9747。由 #9587 引入。