fix(ci): stop stable releases from disabling per-workspace test retries - #10803
Merged
Conversation
The workspace shards passed --retry=0 on stable releases, and a command line option outranks the Vitest config, so the release lane switched off the retry packages/sdk-typescript sets for itself while every other lane kept it. Omit the flag instead of zeroing it, and refresh the stale.yml comment that still described the nightly release as running at 00:00 UTC. Claude-Session: https://claude.ai/code/session_01AWWgJEqafyAT1Mc75T8N7h
Collaborator
|
|
Collaborator
|
Thanks for the PR! Template looks good ✓ Problem: real and verified, not theoretical. On Direction: aligned. Honoring the retry policy each workspace already declares is the consistent behavior; nightly/preview keeping their explicit two retries is unchanged. This is CI configuration, not product release behavior. Size: not applicable (no core paths — CI workflow + scripts test only; 70 additions / 9 deletions). Approach: the scope feels right. Omitting the flag on stable instead of passing Risk: no elevated risk signals — no high-risk paths matched. Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：真实存在且已核实，不是理论问题。当前 方向：对齐。尊重各 workspace 自己声明的重试策略才是自洽的行为；nightly/preview 保留显式的两次重试不变。这是 CI 配置，不涉及产品发布行为。 规模：不适用（未触及核心路径——仅 CI workflow 和 scripts 测试；70 行新增 / 9 行删除）。 方案：范围合理。稳定版不传该参数而不是传 风险：无升级风险信号——未命中高风险路径。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
yiliang114
commented
Sep 2, 2026
yiliang114
left a comment
yiliang114
left a comment
Collaborator
Author
There was a problem hiding this comment.
Reviewed the current head; I found no blocking issues. The stable path now omits the CLI retry override while nightly and preview still pass --retry=2, and the focused release-workflow test passes (45 passed, 1 skipped).
Collaborator
Code reviewNo blockers. Notes from the pass:
Scope is minimal: every hunk serves the stated goal, the two comment lines in stale.yml included. Testing evidenceUnattended CI run — I did not build or execute PR code; the evidence below is the PR's own CI on the reviewed commit, fetched via the API. The two lanes that actually pin this change ( Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 Remaining in-flight checks are the PR's own CI (plus the bot's orchestration jobs, which don't gate). No red checks so far. Not verified: the actual stable-release lane end-to-end — that only runs on a real stable release; the script-level test is the right (and only practical) oracle for the argv change. 中文说明代码审查无阻塞问题。要点：
范围最小化：每个改动都服务于既定目标，包括 stale.yml 的两行注释。 测试证据无人值守 CI 运行——未构建或执行 PR 代码；以下为通过 API 获取的该 PR 自身 CI 在被审提交上的状态。真正钉住此改动的两个通道（运行 scripts 测试套件的 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
|
Confidence: 5/5 — a small, precisely-scoped consistency fix for a verified configuration conflict, with a test that pins the actual command line. My independent take before reading the diff was exactly what this PR does: once you accept that each workspace owns its retry policy, the release lane has no business overriding it with The one thing I can't see from here is the unit suite result on this commit — it was still running at fetch time. Approval is therefore deferred until CI lands green on 中文说明置信度：5/5 —— 小范围、目标精确的一致性修复，解决的是一个已核实的配置冲突，并配有钉住实际命令行的测试。 在读 diff 之前我的独立方案与本 PR 完全一致：既然承认每个 workspace 自己决定重试策略，稳定版发布通道就不该用 唯一在这里看不到的，是该提交上单元测试套件的最终结果——获取时仍在运行。因此批准推迟到 CI 在 — Qwen Code · qwen3.8-max Reviewed at |
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
wenshao
approved these changes
Sep 2, 2026
yiliang114
enabled auto-merge
September 2, 2026 11:36
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. |
Collaborator
|
Released in v0.23.0. |
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
4 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
The release workspace shards stop passing
--retry=0on stable releases. The flag is now omitted entirely there, and still set to 2 for nightly and preview runs. A behavioral test executes the step's script with each schedule's value and asserts which arguments reach the test runner.Also refreshes the comment at the top of the stale-issues workflow, which still justified its 00:30 UTC schedule as trailing a nightly release that no longer runs at 00:00 UTC.
Why it's needed
A command line
--retryoutranks a workspace's own Vitest configuration. The SDK package deliberately configures two retries for itself, and every lane honours that except the stable release lane, which was explicitly zeroing it. That made stable releases stricter than the pull request CI they were validated against: a flake the repository has already decided to absorb could block a real release. Nightly and preview keep the deliberate two retries added for shared-host timing noise.The stale workflow comment is only documentation, but it now asserts a relationship that no longer exists, and the next person tuning either cron would reason from it.
Reviewer Test Plan
How to verify
npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/release-workflow.test.jspasses, 45 tests with one skip.--retry="${VITEST_RETRY}"with0on the stable branch) turns it and the shard pin red.Evidence (Before & After)
N/A (CI configuration). Before, a stable release ran the SDK package as
vitest run --retry=0. After, it runsvitest runand the package's ownretry: 2applies, as it already does everywhere else.Tested on
Risk & Scope
Linked Issues
Follows up on #10765.
中文说明
这个 PR 做了什么
release 的 workspace 分片不再在稳定版发布时传
--retry=0，该场景下完全不传这个参数；nightly 和 preview 仍然是 2。新增一个行为测试，用各个发布场景对应的值执行该步骤的脚本，断言最终传给测试运行器的参数。同时更新 stale workflow 顶部的注释，它仍然以"排在 00:00 UTC 的 nightly 发布之后"来解释自己的 00:30 UTC 排程，而 nightly 已经不在那个时间了。
为什么需要
命令行的
--retry优先级高于各 workspace 自己的 Vitest 配置。SDK 包有意为自己配置了两次重试，除稳定版发布通道外的所有通道都遵循它，而稳定版通道显式把它清零。这让稳定版发布比它所验证的 PR CI 更严格：一个仓库已经决定容忍的抖动会卡住真正的发布。nightly 和 preview 保留为共享机器时间抖动而加的两次重试。stale workflow 的注释只是文档，但它现在断言了一个不存在的关系，下一个调整任一 cron 的人会据此做出错误推断。
评审验证方案
如何验证
npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/release-workflow.test.js通过，45 个用例，1 个跳过。0的--retry="${VITEST_RETRY}"）改回去，该用例和分片固定断言都会变红。前后证据
N/A（CI 配置）。之前稳定版发布以
vitest run --retry=0运行 SDK 包。之后运行vitest run，该包自己的retry: 2生效，与其他所有地方一致。测试平台
风险与范围
关联 Issue
跟进 #10765。
https://claude.ai/code/session_01AWWgJEqafyAT1Mc75T8N7h