ci: apply shared-runner integration limits to release

[yiliang114]

What this PR does

This change passes the actual GitHub runner environment into both Release integration jobs, so the shared self-hosted ECS path uses the single-fork integration-test limit introduced by #10567 while the hosted fallback keeps the existing two-to-four-fork range. A workflow regression test pins the mapping for both the no-sandbox and Docker jobs.

Why it's needed

Release run 33282281913 failed when two qwen serve integration tests repeatedly exceeded the existing 10-second ACP initialization budget under shared-host contention. The Release jobs run on the same ECS pool addressed by #10567, but they did not export RUNNER_ENVIRONMENT; as a result, the integration-test configuration still selected two-to-four Vitest forks there and the new contention limit never applied to Release. This closes that wiring gap without changing the production timeout or weakening the tests.

Reviewer Test Plan

How to verify

Confirm that both Release integration jobs expose the real runner environment to the integration-test process. On a self-hosted runner, the configuration should resolve to one Vitest fork; on the hosted fallback, it should remain at two-to-four forks. The focused workflow and integration configuration suites should stay green.

Local verification: ESLint passed for the changed test; the two focused suites passed 32 tests with one platform-conditional skip; Prettier and git diff --check passed.

Evidence (Before & After)

N/A — CI workflow configuration only.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

Environment (optional)

Local focused workflow-contract and Vitest-configuration tests using the repository's pinned toolchain.

Risk & Scope

• Main risk or tradeoff: Release integration tests on the shared ECS pool trade some wall-clock speed for predictable resource use; the existing 120-minute job ceiling remains unchanged.
• Not validated / out of scope: actual shared-host contention can only be observed in post-merge Release runs; application timeout behavior is unchanged.
• Breaking changes / migration notes: none.

Linked Issues

Fixes #10535

Related: #10567

中文说明

本 PR 做了什么

将实际的 GitHub runner 环境传给 Release 的两个集成测试 job，使共享自托管 ECS 路径能够使用 #10567 引入的单 fork 限制，而托管 fallback 继续保持原有的 2–4 个 fork。新增 workflow 回归测试，固定无沙箱和 Docker 两个 job 的变量接线。

为什么需要

Release run 33282281913 中，两个 qwen serve 集成测试在共享主机资源竞争下反复超过现有的 10 秒 ACP 初始化预算。Release job 使用的正是 #10567 针对的 ECS 池，但此前没有导出 RUNNER_ENVIRONMENT；因此集成测试配置仍在该环境选择 2–4 个 Vitest fork，新的资源竞争限制没有作用于 Release。本 PR 补齐这处接线，不修改生产超时，也不弱化测试。

Reviewer 测试计划

如何验证

确认 Release 的两个集成测试 job 都会把真实 runner 环境传给集成测试进程。在自托管 runner 上，配置应解析为一个 Vitest fork；在托管 fallback 上，应保持 2–4 个 fork。聚焦的 workflow 与集成配置测试应保持通过。

本地验证：修改的测试文件已通过 ESLint；两个聚焦测试套件共 32 个测试通过、1 个平台条件跳过；Prettier 和 git diff --check 均通过。

证据（修改前后）

N/A——仅修改 CI workflow 配置。

测试平台

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

环境（可选）

使用仓库锁定的工具链在本地运行聚焦的 workflow contract 与 Vitest 配置测试。

风险与范围

• 主要风险或权衡：共享 ECS 池上的 Release 集成测试以部分墙钟时间换取可预测的资源使用；现有 120 分钟 job 上限保持不变。
• 未验证 / 范围外：真实共享主机资源竞争只能在合入后的 Release run 中观察；应用层超时行为保持不变。
• 破坏性变更 / 迁移说明：无。

关联 Issue

Fixes #10535

相关：#10567

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[qwen-code-ci-bot]

Thanks for the PR!

• Template: looks good ✓
• Problem: observed failure, not theory — nightly release run 33282281913 failed on integration_none (auto-filed issue Release Failed for v0.22.3-nightly.20260830.413b6d15d3 on 2026-08-30 #10535, still open) when integration tests exceeded the ACP init budget under shared-host contention. The wiring gap is real: ci: serialize E2E tests on shared ECS runners #10567 added the one-fork limit keyed on RUNNER_ENVIRONMENT in integration-tests/vitest.config.ts, and e2e.yml exports the variable, but release.yml never did.
• Direction: aligned — this extends the already-merged ci: serialize E2E tests on shared ECS runners #10567 pattern to the one lane it missed. CI wiring only: no product behavior, no timeout change, no tests weakened. It does touch release.yml, but the change only affects the two integration-test jobs' environment, and the author is a maintainer, so I'm not escalating on release-surface grounds.
• Size: not core. 2 workflow lines + 8 test lines.
• Approach: minimal — one env var per integration job plus a regression test pinning both jobs. One observation: it's set at job level (vs. step level in e2e.yml), so build steps also see the variable — harmless, nothing else reads it, and the new test pins the job-level placement. Nothing to cut.
• Risk: no high-risk path matches; no elevated risk signals.

Moving on to code review. 🔍

中文说明

感谢贡献！

• 模板：完整 ✓
• 问题：真实观测到的故障，不是理论问题——nightly release run 33282281913 在 integration_none 上失败（自动创建的 issue Release Failed for v0.22.3-nightly.20260830.413b6d15d3 on 2026-08-30 #10535，仍然 open），集成测试在共享主机资源竞争下超过了 ACP 初始化预算。接线缺口确实存在：ci: serialize E2E tests on shared ECS runners #10567 在 integration-tests/vitest.config.ts 中加入了依赖 RUNNER_ENVIRONMENT 的单 fork 限制，e2e.yml 导出了该变量，但 release.yml 一直没有。
• 方向：对齐——把已合入的 ci: serialize E2E tests on shared ECS runners #10567 模式补到唯一漏掉的 lane。仅 CI 接线：不改产品行为、不改超时、不弱化测试。它确实改动了 release.yml，但改动只影响两个集成测试 job 的环境变量，且作者是 maintainer，因此不以 release 面为由升级。
• 规模：未触及核心路径。2 行 workflow + 8 行测试。
• 方案：最小化——每个集成测试 job 加一个环境变量，并新增回归测试固定两个 job 的接线。一点观察：放在 job 级（而非 e2e.yml 的 step 级），build 步骤也能看到该变量——无害，没有其他地方读取它，且新测试固定了 job 级位置。没有可砍的部分。
• 风险：未命中高风险路径；无升级风险信号。

进入代码审查 🔍

— Qwen Code · qwen3.8-max

_{Reviewed at f82c79337e25f0d0ce83938a5e44386c2f0663e5 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Code review

Independent baseline first: given "the release lane misses #10567's fork cap because RUNNER_ENVIRONMENT is never exported", the obvious fix is exactly what this PR does — export the variable in both release integration jobs and pin the wiring with a workflow test. The diff matches that baseline; I found no simpler path.

• integration_none and integration_docker are the only jobs in release.yml that run the integration suite, and both reach it through integration-tests/vitest.config.ts — the single reader of RUNNER_ENVIRONMENT (via the test:integration:* npm scripts and the direct npx vitest run --root ./integration-tests calls). Job-level env reaches every step, but nothing else in those jobs reads the variable, so the placement is safe, and the new test pins it.
• Effect on the shared ECS pool: forks go from 2–4 to exactly 1. One side effect worth naming: the same flag also switches on dangerouslyIgnoreUnhandledErrors for self-hosted Linux in that config. That matches the config's own comment (self-hosted runners are deliberately exempted from the pressure-class unhandled-error flakes) and what e2e.yml already does on the same pool — consistent rather than new risk, but it is a second behavior riding on this wiring, so it's called out here.
• The regression test sits in the existing release lane runner routing describe block, matches the file's style, and fails if either job drops the variable — i.e. the suite does not pass identically with the diff removed.
• No blockers, no convention violations.

Testing evidence

This is an unattended CI run, so the evidence below is the PR's own CI check results fetched once through the API (PR code was not built or executed here).

Check	Conclusion
Test (ubuntu-latest, Node 22.x)	⏳ in progress — runs test:scripts, which covers the new release-workflow.test.js case
Integration Tests (no-AK, No Sandbox)	⏳ in progress
Dependency CVE audit	✅ success
Secret scan (TruffleHog)	✅ success
Desktop Shell (ubuntu-22.04 / windows-2022)	✅ success
Test (macos-latest / windows-latest), Integration Tests (CLI, No Sandbox)	⏭️ skipped by design — these lanes only run on merge_group / schedule / dispatch
review-pr, triage, other bot orchestration	⏳ / ⏭️ bot jobs, not PR signal

No red checks at fetch time; the two lanes that actually exercise this diff (the unit/scripts suite and the no-AK integration gate) were still running, so the table above will be updated in place by the finalize job once CI settles. One thing pre-merge CI structurally cannot show: whether the contention relief actually holds in real release runs — that only becomes observable in post-merge nightly runs on the shared ECS pool, and no sandboxed lane (/verify, /tmux) can reproduce shared-host pressure, so nothing is being deferred to one.

中文说明

代码审查：先写独立方案再对照——针对"release lane 缺少 #10567 的单 fork 限制，因为从未导出 RUNNER_ENVIRONMENT"，最直接的修法就是本 PR 的做法：在两个 release 集成测试 job 中导出该变量，并用 workflow 测试固定接线。实际 diff 与该方案一致，没有找到更简路径。

• integration_none 和 integration_docker 是 release.yml 中仅有的两个跑集成测试的 job，且都经由 integration-tests/vitest.config.ts（RUNNER_ENVIRONMENT 的唯一读取方）。job 级 env 会传到所有步骤，但这些 job 中没有其他步骤读取该变量，位置安全，且新测试已固定。
• 在共享 ECS 池上：fork 数从 2–4 变为固定 1。一个值得点名的附带效果：同一开关还会在 self-hosted Linux 上启用该配置里的 dangerouslyIgnoreUnhandledErrors。这与配置自身注释（self-hosted runner 有意豁免压力类 unhandled-error 抖动）以及 e2e.yml 在同一池子上的既有行为一致——是一致性而非新风险，但它毕竟是这处接线带来的第二个行为，故在此说明。
• 回归测试放在已有的 release lane runner routing describe 块中，风格与文件一致；任一 job 丢失该变量都会使测试失败——即去掉本 diff 后测试套件不会同样通过。
• 无阻塞项，无规范违规。

测试证据：本次为无人值守 CI 运行，以上证据为通过 API 一次性获取的 PR 自身 CI 检查结果（此处未构建或执行 PR 代码）。获取时无红色检查；真正覆盖本 diff 的两条 lane（ubuntu 单测/脚本套件、no-AK 集成门禁）仍在运行，表格将由 finalize 任务在 CI 结束后就地更新。预合入 CI 在结构上无法展示的一点：竞争缓解是否在真实 release run 中生效——只能在合入后的 nightly run（共享 ECS 池）中观察，任何沙箱 lane（/verify、/tmux）都无法复现共享主机压力，因此未将其转给沙箱验证。

— Qwen Code · qwen3.8-max

_{Reviewed at f82c79337e25f0d0ce83938a5e44386c2f0663e5 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 5/5 — clean across every stage; a two-line wiring fix that exactly matches the independently-derived approach and pins itself with a regression test.

This is the remainder of #10567 that never got wired up: the release lane runs on the same shared ECS pool but never exported RUNNER_ENVIRONMENT, so the one-fork cap and the pressure-class unhandled-error exemption silently never applied to it — and run 33282281913 is what that omission cost. The diff is the minimum change that fixes it: one env var per integration job, plus a test that fails if either job drops it. No scope creep, no drive-bys, and the one side effect (the unhandled-error exemption coming along with the fork cap) is the config's intended self-hosted semantics, already live on the same pool via e2e.yml. If I'm maintaining this in six months, the new test tells me exactly what the wiring is supposed to be. Approving — but the two CI lanes that actually exercise the diff (ubuntu unit/scripts suite and the no-AK integration gate) are still running, so approval is deferred until CI lands green on f82c79337e25f0d0ce83938a5e44386c2f0663e5; the finalize job will post the commit-pinned approval then, or withhold it if anything lands red.

中文说明

Confidence: 5/5 —— 各阶段全部干净；一个两行接线修复，与独立推导出的方案完全一致，并用回归测试把自己固定住。

这就是 #10567 一直没接上的剩余部分：release lane 跑在同一个共享 ECS 池上，却从未导出 RUNNER_ENVIRONMENT，于是单 fork 上限和压力类 unhandled-error 豁免一直没有作用于它——run 33282281913 就是这个缺口的代价。该 diff 是修复它的最小改动：每个集成测试 job 一个环境变量，外加一个在任一 job 丢失该变量时失败的测试。没有范围蔓延、没有顺手改动；唯一的附带效果（unhandled-error 豁免随 fork 上限一起生效）是该配置对 self-hosted 的预期语义，且已通过 e2e.yml 在同一池子上生效。六个月后维护这段代码时，新增的测试能准确告诉我接线应该是什么样。批准——但真正覆盖该 diff 的两条 CI lane（ubuntu 单测/脚本套件、no-AK 集成门禁）仍在运行，因此批准推迟到上述提交的 CI 全绿之后；finalize 任务届时会提交绑定该 commit 的批准，若有红色结果则会扣下。

— Qwen Code · qwen3.8-max

_{Reviewed at f82c79337e25f0d0ce83938a5e44386c2f0663e5 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Released in v0.23.0.