ci: add hk ECS runners to update-ecs-runner matrix - #8599
Conversation
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
@yiliang114 The change itself reads fine, but the PR body skips the PR template entirely — no ## What this PR does / ## Why it's needed / ## Reviewer Test Plan / ## Risk & Scope / ## Linked Issues headings and no Chinese <details> block. Your own recent PRs (#8518, #8511) follow it, and for a change to the self-hosted runner fleet the Reviewer Test Plan and Risk & Scope sections are exactly where the interesting bits live — e.g. how a reviewer confirms the two hk machines actually pick up the release dispatch, and what happens on a dispatch if a label matches no online runner.
Could you reformat the body to the template? The prose you already wrote maps onto it nearly one-to-one, so this should be a quick edit — then re-run triage with @qwen-code /triage.
中文说明
@yiliang114 改动本身看起来没问题,但 PR 正文完全没有使用 PR 模板——缺少 ## What this PR does / ## Why it's needed / ## Reviewer Test Plan / ## Risk & Scope / ## Linked Issues 等标题,也没有中文 <details> 翻译块。你最近的 PR(#8518、#8511)都是按模板填写的;而且对于自托管 runner 机群的变更,Reviewer Test Plan 和 Risk & Scope 恰恰是最关键的部分——例如 reviewer 如何确认两台 hk 机器真的会响应发布 dispatch、以及 dispatch 时如果某个 label 没有匹配的在线 runner 会发生什么。
能否按模板重新排版正文?你已经写好的内容几乎可以一一对应填进去,应该很快就能改完——之后用 @qwen-code /triage 重新触发即可。
— Qwen Code · qwen3.8-max
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. |
|
Released in v0.21.7. |
What this PR does
Adds the two already-existing hk runner labels (
ecs-update-hk-1,ecs-update-hk-2) to theupdate-ecs-runner-qwenworkflow's update matrix, so the two hk machines receive the automatic post-release qwen update alongside the already-covered 64c and sg machines.Why it's needed
The matrix only listed
ecs-update-sgandecs-update-64c. The two hk machines already carry distinct labels (ecs-update-hk-1/ecs-update-hk-2) but were absent from the matrix, so the post-releaserepository_dispatch(npm-published) update never scheduled a job on them and they stayed on old qwen versions. 64c and sg are each a single machine with several co-located runner processes, so their shared labels are correct as-is; only the hk entries were missing.Reviewer Test Plan
How to verify
After merge, dispatch
update-ecs-runner-qwen.ymlwithversion=0.21.6. The run should fan out to 4 jobs (sg, 64c, hk-1, hk-2) instead of 2, and each job's "Verify version" step assertsqwen --versionequals the resolved 0.21.6 — all 4 succeeding confirms every machine updated.Evidence (Before & After)
N/A (CI workflow change). Before: release-triggered run 31022904130 produced 2 jobs (sg, 64c). After: 4 jobs expected (sg, 64c, hk-1, hk-2).
Tested on
Environment (optional)
N/A — workflow-only change; validated by the update run on the self-hosted Linux runners post-merge.
Risk & Scope
Linked Issues
N/A — follow-up to the ECS runner auto-update gap discussed during the v0.21.6 release.
中文说明
这个 PR 做了什么
把两个已存在的 hk runner 标签(
ecs-update-hk-1、ecs-update-hk-2)加入update-ecs-runner-qwenworkflow 的更新矩阵,使两台 hk 机器能和已覆盖的 64c、sg 机器一样,在发版后自动更新 qwen。为什么需要
矩阵原先只列了
ecs-update-sg和ecs-update-64c。两台 hk 机器虽然已带独立标签,但不在矩阵里,因此发版后的repository_dispatch(npm-published)更新从不会调度到它们,导致停留在旧版本。64c 和 sg 各是一台机器、多个 runner 进程同机,共享标签本身没问题;缺的只是 hk 两项。审查者测试计划
如何验证
merge 后以
version=0.21.6触发update-ecs-runner-qwen.yml,run 应从 2 个 job 变为 4 个(sg、64c、hk-1、hk-2),且每个 job 的 "Verify version" 步骤断言qwen --version等于 0.21.6——4 个全 success 即代表 4 台都更新成功。证据(前后对比)
N/A(CI workflow 改动)。之前:release 触发的 run 31022904130 只有 2 个 job;之后:预期 4 个。
测试平台
macOS N/A;Windows N/A;Linux ✅(self-hosted runner 上验证)。
风险与范围
关联 Issue
N/A——v0.21.6 发布期间发现的 ECS runner 自动更新缺口的后续。