qwen-code 的 Windows CI 验证：在自托管 ECS Runner 上运行不削弱安装器覆盖的测试门

qwen-code 的 Windows CI 验证在自托管 ECS Runner 上运行不削弱安装器覆盖的测试门【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code本文基于 qwen-code 仓库中的设计文档 windows-ecs-ci-validation.md系统讲解该项目如何把 Windows 测试门从托管 runner 迁移到自托管 ECS runnerecs-win包括跨平台测试的失败分类策略、必须保留的 Windows 安装器覆盖、ci.yml 中test_windows作业的路由与回退机制以及维护者紧急开关MAINTAINER_ECS_RUNNER_DISABLED的运维语义。读完本文你能掌握一条完整的自托管 Windows CI 门设计链路从测试分类、workflow 路由、composite action 环境调优到队列阻塞应急处理。背景为什么要迁到自托管 ECS Runner原设计文档给出的目标只有一句话在不削弱 Windows 特定安装器覆盖的前提下把必需的 Windows 测试门跑在自托管 ECS runner 上。仓库中的佐证表明这不是单纯换机器而是一次带完整安全考量的迁移CHANGELOG.md 记录了该变更的动机——Windows 合并队列测试默认跑在已验证的ecs-win自托管 runner 上以降低对托管 runner 池的依赖ci.yml 中test_windows作业上方的注释详细解释了安全约束runs-on表达式中专门保留了github.event_name ! pull_request这一分支因为pull_request事件执行的是 PR 自身合并提交的 workflow YAML——任何被该 lane 放行的 PR 都可能在同一份 diff 里改写runs-on被门控的树控制了门本身那就不再是门。所以ecs-win池只接受未审查 PR 无法触发的触发源审批后的合并队列merge_group、定时任务和手动 dispatch。test_windows作业的完整入口条件ci.ymltest_windows: name: Test (windows-latest, Node 22.x) needs: classify_pr if: |- ${{ !cancelled() ( github.event_name merge_group || github.event_name schedule || github.event_name workflow_dispatch ) }} runs-on: ${{ vars.MAINTAINER_ECS_RUNNER_DISABLED ! true github.event_name ! pull_request fromJSON([self-hosted, Windows, X64, ecs-win]) || fromJSON([windows-2022]) }} timeout-minutes: 60注意两个细节作业名刻意保持为Test (windows-latest, Node 22.x)不变以匹配 required status check 上下文timeout-minutes: 60是作业级上限。失败分类策略什么能在 Windows 上跑、什么必须跳过迁移的核心风险是大量脚本测试依赖 POSIX 语义直接搬到 Windows 会产生噪音失败。设计文档给出了四条分类规则这里逐条结合仓库源码展开。规则一跨平台断言必须使用平台原生路径与解析后的 fixture 根。这意味着断言不能硬编码/分隔符或绝对路径假设测试要拿到解析后的 fixture 根再比较。规则二POSIX 独占的文件系统契约跳过仅限 Windows 无法表达 fixture 的个别用例。文档列举了四类典型契约可执行 mode bit、文件名中的控制字节、权限失败如chmod后断言EACCES、替换一个仍被打开的文件POSIX 允许、Windows 拒绝。对应实现落在 scripts/tests/vitest.config.ts——当process.platform win32时追加排除列表exclude: process.platform win32 ? [ ...configDefaults.exclude, scripts/tests/e2e-shard-retry.test.js, scripts/tests/security-checks-audit-retry.test.js, scripts/tests/pr-self-report-label.test.js, // Bash-driven workflow suites cannot run on Windows; pure // YAML-parse workflow suites still do. scripts/tests/qwen-*-workflow.test.js, scripts/tests/serve-ab-workflow.test.js, ] : [...configDefaults.exclude],注意注释区分了两类 workflow 套件Bash 驱动的qwen-*-workflow.test.js整体排除而纯 YAML 解析的 workflow 套件仍然在 Windows 上运行——这正是文档第四条规则跨平台脚本测试保持启用的落地。规则三作业只跑在 Linux 的 workflow其测试从 Windows 脚本套件中排除Linux CI 仍是其可达产物与权威覆盖。即排除不是放弃覆盖而是把权威覆盖留在 Linux 一侧。规则四跨平台脚本测试保持启用POSIX 独占的 subprocess fixture 逐个加守卫而不是排除整个可移植测试文件。这与上面的整文件排除形成对照能守卫的用例留在文件里避免排除文件 → 文件里可移植用例也在 Windows 上消失的覆盖损失。必需的 Windows 覆盖install-script.test.js 与九个安装器端到端用例设计文档明确Windows 脚本套件必须继续运行 install-script.test.js包含全部九个 Windows 安装器端到端用例及其安全检查其他已在 Windows 上通过的脚本测试也保持启用。源码佐证九个端到端用例集中在 install-script.test.js 的describe(Windows installer end-to-end)块中通过itOnWindows(...)守卫仅在实际 Windows 环境执行。其中一个用例的形态是创建一个伪造的 standalone 归档 → 运行安装器 → 断言bin\qwen.cmd与qwen-code\node\node.exe存在 → 断言~\.qwen\source.json内容 → 调用qwen.cmd --version验证版本输出。这解释了为什么 Windows runner 上该套件显著变慢——scripts/tests/vitest.config.ts 的注释记录了install-script.test.js会 shell out 到node运行create-standalone-package.js在 Windows 上会经历完整的 targzip 流程且处于杀毒软件扫描之下实测 4780ms / 1666ms / 1079ms最慢一次恰好贴着 vitest 默认 5s 上限而 flake后来在共享池上同一工作又慢约 5 倍最终整套脚本套件的testTimeout定为 90s可用QWEN_SCRIPTS_TEST_TIMEOUT_MS环境变量覆盖并用||而非??兜底防止 workflow 渲染的空字符串把超时上限悄悄解除Number() 0在 vitest 语义里是无超时。这条必须保留规则本身有测试守护no-ak-integration-ci.test.js 中有用例keeps install-script.test.js out of the win32 exclude list断言install-script.test.js不会出现在 vitest 配置的 win32 排除列表里——防止未来有人图省事把它一并排除。同一文件no-ak-integration-ci.test.js还锁定了runs-on路由表达式的精确文本即上文展示的MAINTAINER_ECS_RUNNER_DISABLED三元路由路由写法变更会先在测试里报错。test_windows 门的环境装配自托管分支与托管回退分支test_windows作业的步骤按runner.environment分叉设计文档所称回退不是字节级等价的环境就体现在这里。逐步骤拆解ci.yml步骤自托管ECS行为托管windows-2022回退行为Disable Git CRLF conversioncheckout之前执行git config --global core.autocrlf false配合.gitattributes的eollf双保险仅在runner.environment self-hosted时运行不运行——这就是文档所说的pre-checkout autocrlf 步骤是 self-hosted-onlyConfigure Windows test environment调用仓库内 composite action configure-windows-runner改为内联的 Point temp at a short-alias-free directory 步骤托管 runner 的TEMP经 8.3 短别名暴露故把TEMP/TMP指到$RUNNER_WORKSPACE\qwen-code-tempVerify checkout includes expected head commit两者都运行PR 与 merge_group 事件下用 verify-checkout-head 防止自托管 runner 的 stale checkout 静默测试错误的树同左Node 来源self-hosted-node 复用机器预装 Node避免 ECS 经出口代理访问 nodejs.org 下载actions/setup-node安装 Node 22.xnpm 缓存持久缓存目录${HOME}/.cache/qwen-code/npm写入NPM_CONFIG_CACHE无此步骤npm 限流参数两者都设fetch-retry-mintimeout 20000、fetch-retry-maxtimeout 120000、fetch-retries 5、fetch-timeout 300000同左运行测试npm run test:ci并附带每 10s 采样TMPDIR磁盘/inode/内存的后台监视器失败时 dump 全量df/meminfo 现场同左其中 configure-windows-runner 做三件事其描述与文档locale env、TEMP/TMP 重定向、Git Bash 上 PATH逐字对应把TEMP/TMP重定向到RUNNER_TEMP自托管 runner 保持配置好的、无别名的RUNNER_TEMP路径导出LC_ALLC.UTF-8镜像 Linux 门的 locale 环境在 Windows 上是惰性的因为 Node 经 ICU 做 collation把C:\Program Files\Git\bin追加到GITHUB_PATH让后续步骤能按 workflow 级默认的 bash shell 运行。该 action 必须放在actions/checkout之后因为仓库内./相对路径的 action 是从作业工作区解析的——这一约束在 ci.yml 的注释中有明确说明。此外还有一个跨平台细节ci.yml 的 Verify temp paths carry no short alias 步骤用 Node 比较realpathSync结果时大小写不敏感——Windows 路径大小写不敏感仅大小写差异是同一目录不能误判为 8.3 别名而RUNNER~1 → runneradmin这类真正的别名差异会因超出大小写差异而仍然报错。Runner 冒烟验证windows-runner-smoke.yml自托管 runner 环境变更后需要一条可随时触发的验证路径。windows-runner-smoke.yml 就是这个角色它的validate作业只由workflow_dispatch手动触发runs-on固定为[self-hosted, Windows, X64, ecs-win]timeout-minutes: 60刻意镜像ci.yml的 Windows 合并队列门checkout 前先关 autocrlfcheckout 后走同一个configure-windows-runner再走同一个verify-checkout-head因为 smoke 走同一套带缓存的出口代理若 checkout 缺少被 dispatch 的 head 必须响亮失败而不是验证了错误的树Verify tools 步骤逐项断言TEMP确实被重定向到RUNNER_TEMP不等则抛错、Node 主版本 ≥ 22、npm/qwen/gh可用Verify symbolic links 步骤实测创建并读取符号链接——符号链接是 Windows runner 上测试 fixture 的常见前提与门相同的 Node 路径self-hosted-node、相同格式的 npm 缓存与限流配置、相同的 bash shell 与测试环境变量清空所有 API key、HOME/USERPROFILE指向runner.temp下的隔离目录最后执行与门完全一致的npm run test:ci。package.json 中test:ci的构成是理解完整验证含义的关键test:ci:workspaces: cross-env NODE_OPTIONS\--max-old-space-size3072\ npm run test:ci --workspaces --if-present --, test:ci: npm run test:ci:workspaces npm run test:scripts, test:scripts: vitest run --config ./scripts/tests/vitest.config.ts即各 workspace 包的单测 脚本测试套件含上文讨论的 win32 排除逻辑这就是 Windows ECS runner 上完整npm run test:ci的实际范围。验证门什么条件下变更才算就绪设计文档给出的验收标准分两级本地适用处格式化检查、lint 配置检查、目标化的 CLI 与 core 测试、脚本套件通过Windows ECS runner 上完整npm run test:ci通过。结合上文的路由规则可以推断本地开发者实际可复现的是第 1 级第 2 级依赖ecs-win或回退的windows-2022环境特有的行为杀毒扫描下的耗时、符号链接、短别名等因此被放在门的一端作为最终裁决。运维runner 离线时的队列阻塞与紧急开关这是设计文档中最具实战价值的部分原文的完整语义如下配合 ci-platform-lanes.test.js 等测试中对同一开关的引用逐条展开。问题离线不报错而是排队。当ecs-winrunner 离线时作业不是失败而是进入队列等待——这会阻塞整个 merge queue直到维护者介入。因为runs-on是标签匹配没有 runner 在线就永远等不到匹配。开关MAINTAINER_ECS_RUNNER_DISABLED仓库变量。将其设为true后runs-on表达式的左支短路失败Windows 门回落到windows-2022。但该开关有两个必须理解的边界已入队的运行不会重新求值runs-on。已经排在离线ecs-win标签下的 run 会继续等待而且timeout-minutes不计入排队时间——所以翻转开关后必须手动取消或重跑这些已排队的 run否则它们仍会挂住。回退环境不是字节级等价。pre-checkout 的 autocrlf 步骤和configure-windows-runner的整套调优locale env、TEMP/TMP 重定向、Git Bash 上 PATH都是 self-hosted-only托管回退跑的是迁移前的作业形态——因此回退期间的绿色结果只能证明主干未被破坏不能证明 ECS 配置本身有效ECS 配置要靠 windows-runner-smoke.yml 单独验证。容量单台健康但繁忙的ecs-win也会串行化队列。ecs-win池只有一台机器而托管windows-2022池原本可并行处理合并队列条目迁到单台自托管机后并发队列条目必须排队等这一台机器。从 ci.yml 中 Linux 侧的对应处理可以印证这类权衡的普遍性ECS 共享主机上仅安装依赖就可能超过 30 分钟因此integration_no_ak作业的超时按是否落在ecs-qwen上动态取 60 或 30 分钟。小结与深入阅读路径这条 Windows CI 设计可以用三句话概括用分类规则把不可移植的测试隔离掉而不是砍掉 Windows 门用一条镜像门的 smoke workflow 持续验证自托管 runner 本身用一个仓库变量开关在 runner 离线时把门打回托管池并接受回退不等价、排队需人工清的两个已知代价。如需继续深入建议按以下顺序阅读仓库文件docs/design/windows-ecs-ci-validation.md本文的设计原文ci.ymltest_windows作业完整定义路由、分叉步骤、测试执行windows-runner-smoke.ymlrunner 冒烟验证全流程.github/actions/configure-windows-runner/action.yml自托管 Windows 环境调优的 composite actionscripts/tests/vitest.config.tswin32 排除列表与超时策略scripts/tests/install-script.test.js九个 Windows 安装器端到端用例scripts/tests/no-ak-integration-ci.test.js对路由表达式与排除列表的测试守护。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考