ci: matrix ECS runner update + sudo install + repository_dispatch trigger

[yiliang114]

Summary

The existing update-ecs-runner-qwen.yml workflow has two issues that prevent it from reliably keeping ECS runners on the latest qwen-code version:

1. Wrong install target. The runner service runs as the github-runner user (/home/github-runner/actions-runner-N/). When the workflow executes npm install -g, npm resolves the global prefix to the runner user's home directory. However, /usr/local/bin (where root originally installed qwen 0.20.0) appears earlier in PATH, so qwen --version still returns the old version and the verify step fails. The changed 7 packages output from npm is real — it just lands in the wrong place.

2. Single-runner scheduling. The runs-on label ecs-qwen matches multiple runners, but each workflow_dispatch only schedules one job, leaving the other runner(s) unupdated.

Changes

• Matrix strategy (ecs-update-sg, ecs-update-64c) with fail-fast: false so both runners are updated in parallel and independently.
• sudo npm install -g unconditionally, ensuring the package lands in /usr/local — the system-wide prefix that every user's PATH resolves first.
• Job-level per-runner concurrency group (update-ecs-runner-qwen-${{ matrix.runner }}) so updates on the same runner queue instead of overlapping, while the two matrix jobs don't block each other.
• repository_dispatch (npm-published) so release.yml can trigger runner updates automatically after a publish (follow-up PR to wire the dispatch call). The resolve step reads client_payload.version so a release-triggered dispatch pins the exact published version instead of racing the npm latest dist-tag propagation.
• Register the new self-hosted labels in .github/actionlint.yaml so actionlint keeps passing.

Prerequisite

Each ECS runner needs a unique label added in Settings → Actions → Runners:

Instance	New label
i-t4neqpisqczs6hsm7xn2 (sg-1)	ecs-update-sg
i-t4ne2fxw78cka1n2cbko (64c)	ecs-update-64c

The existing shared ecs-qwen label should be kept so other workflows (qwen-code-pr-review.yml, qwen-triage.yml) continue to work without changes.

Test plan

• Add ecs-update-sg / ecs-update-64c labels to the two ECS runners in GitHub Settings.
• One-time cleanup on both instances: remove the stale copy previously installed into the runner user's npm prefix (npm uninstall -g @qwen-code/qwen-code as github-runner), then sudo npm install -g @qwen-code/qwen-code@latest.
• Trigger the workflow via workflow_dispatch and verify both matrix jobs succeed.
• Confirm qwen --version returns the latest version on both runners after the run.

[qwen-code-ci-bot]

Thanks for the PR!

Template: the body covers what/why/test-plan under different headings (Summary / Test plan instead of the template's What this PR does / Why it's needed / Reviewer Test Plan). Content is all there — not blocking on heading names for a CI-only change, but worth matching the template next time.

Problem: observed and concrete. The existing workflow installs into the runner user's npm prefix, which is shadowed by the older root-installed binary in /usr/local/bin — so qwen --version still returns the old version and the verify step fails. The single-runner scheduling issue (shared ecs-qwen label, one job per dispatch) is also a real operational gap. Both are clearly from hands-on experience with these runners.

Direction: straightforward CI maintenance — keeping self-hosted runners on the latest qwen-code version. No product-direction concerns.

Size: not applicable (no core paths touched — two CI config files, +19/−17).

Approach: the scope feels right. Matrix strategy for both runners, unconditional sudo to land in the system prefix, per-runner concurrency group, and a repository_dispatch trigger for post-publish automation — each change maps directly to a stated problem. The previous review flagged that concurrency at the workflow level couldn't resolve ${{ matrix.runner }} — this revision moves it under the update job, which is the correct fix. The repository_dispatch trigger stays inert until the follow-up PR wires the dispatch call from release.yml, which is fine.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板：PR 正文用不同的标题（Summary / Test plan）覆盖了"做什么/为什么/测试计划"的内容。内容齐全——对于纯 CI 改动不因标题名称阻塞，但下次建议匹配模板格式。

问题：已观测到的具体问题。现有 workflow 安装到 runner 用户的 npm 前缀，被 /usr/local/bin 中旧的 root 安装版本遮蔽——qwen --version 仍返回旧版本，验证步骤失败。单 runner 调度问题（共享 ecs-qwen 标签，每次 dispatch 只跑一个 job）也是实际的运维缺口。两者都明显来自对这些 runner 的实际操作经验。

方向：直接的 CI 维护——保持自托管 runner 上的 qwen-code 版本最新。无产品方向顾虑。

规模：不适用（未触及核心路径——两个 CI 配置文件，+19/−17）。

方案：范围合理。Matrix 策略覆盖两个 runner、无条件 sudo 安装到系统前缀、按 runner 的并发组、repository_dispatch 触发器用于发布后自动化——每项改动都直接对应所述问题。上次审查指出 workflow 层级的 concurrency 无法解析 ${{ matrix.runner }}——本次修订将其移到了 update job 下，是正确的修复。repository_dispatch 触发器在后续 PR 接入 release.yml 的 dispatch 调用前保持惰性，没问题。

进入代码审查 🔍

— Qwen Code · qwen3.8-max-preview

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

[qwen-code-ci-bot]

Code Review

Independent proposal: for the stated problems (wrong install prefix shadowed by /usr/local/bin, single-runner scheduling), I'd do exactly what this PR does — matrix over per-runner labels, unconditional sudo npm install -g, job-level concurrency groups, and a repository_dispatch hook for future automation.

Diff review: the implementation matches. Specifics:

• The matrix + fail-fast: false is correct — a failure on one runner won't cancel the other.
• The install step simplification (13 lines of conditional → 1 sudo npm install -g) is the right call. The old code's writable-check path was the root cause of the shadowing bug — npm installed into the runner user's home prefix while /usr/local/bin (root-installed) took precedence in PATH.
• The concurrency group is now correctly at the job level with ${{ matrix.runner }}, giving true per-runner isolation between separate workflow runs. This addresses the concern from the previous review.
• The if: "${{ github.repository == 'QwenLM/qwen-code' }}" guard is preserved, so dispatch triggers won't fire in forks. Good.
• Version resolution: ${{ inputs.version || github.event.client_payload.version }} correctly handles both workflow_dispatch (manual) and repository_dispatch (automated, pins the published version).
• The actionlint.yaml additions register the two new self-hosted labels so actionlint keeps passing. Clean.
• YAML validates cleanly.

No correctness bugs, security issues, or convention violations found.

Real-Scenario Testing

This PR modifies GitHub Actions workflow files — it has no CLI runtime behavior to exercise in tmux. The workflow can only be validated end-to-end by running it on the actual ECS runners via workflow_dispatch, which requires the prerequisite runner labels (ecs-update-sg, ecs-update-64c) to be configured in GitHub Settings first.

What was verified locally:

$ python3 -c "import yaml; yaml.safe_load(open('.github/workflows/update-ecs-runner-qwen.yml')); print('YAML valid')"
YAML valid

$ gh pr diff 7513 --repo QwenLM/qwen-code | git apply --stat
 .github/actionlint.yaml                        |  2 ++
 .github/workflows/update-ecs-runner-qwen.yml   | 34 +++++++++++++-------------
 2 files changed, 19 insertions(+), 17 deletions(-)

The diff applies cleanly to main and the resulting YAML parses without errors. CI checks on the PR are green (ubuntu tests pass, web-shell E2E passes).

中文说明

代码审查

独立方案： 针对所述问题（安装前缀被 /usr/local/bin 遮蔽、单 runner 调度），我会做和这个 PR 一样的事——按 runner 标签做 matrix、无条件 sudo npm install -g、job 层级并发组、repository_dispatch 钩子用于未来自动化。

Diff 审查： 实现与独立方案一致。具体：

• Matrix + fail-fast: false 正确——一个 runner 失败不会取消另一个。
• 安装步骤简化（13 行条件判断 → 1 行 sudo npm install -g）是正确选择。旧代码的可写检查路径正是遮蔽 bug 的根因——npm 安装到 runner 用户的主目录前缀，而 /usr/local/bin（root 安装）在 PATH 中优先。
• concurrency 组现在正确地在 job 层级使用 ${{ matrix.runner }}，实现了不同 workflow run 之间真正的按 runner 隔离。解决了上次审查的顾虑。
• if: "${{ github.repository == 'QwenLM/qwen-code' }}" 守卫保留了，dispatch 触发器不会在 fork 中触发。好。
• 版本解析：${{ inputs.version || github.event.client_payload.version }} 正确处理 workflow_dispatch（手动）和 repository_dispatch（自动，锁定发布版本）。
• actionlint.yaml 新增注册了两个自托管标签，actionlint 可以通过。干净。
• YAML 验证通过。

未发现正确性 bug、安全问题或规范违反。

实际场景测试

此 PR 修改的是 GitHub Actions workflow 文件——没有可在 tmux 中执行的 CLI 运行时行为。只能通过在实际 ECS runner 上通过 workflow_dispatch 运行来端到端验证，前提是先配置好 runner 标签（ecs-update-sg、ecs-update-64c）。

本地已验证：YAML 语法正确，diff 可干净地应用到 main。PR 上的 CI 检查通过（ubuntu 测试通过，web-shell E2E 通过）。

— Qwen Code · qwen3.8-max-preview

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

[qwen-code-ci-bot]

Confidence: 4/5 — clean, focused CI fix that solves two real operational problems; the previous review's concern about workflow-level concurrency has been addressed in this revision.

This is exactly the kind of PR that's easy to review and easy to maintain in six months. The diff is 36 lines across two files, every change maps to a stated problem, and the install step went from a fragile 13-line conditional (which was the root cause of the shadowing bug) to a single sudo npm install -g with a clear comment explaining why. The matrix strategy is the standard GitHub Actions pattern for multi-runner updates, and the repository_dispatch hook is a sensible forward-looking addition that stays inert until wired up.

The previous review's only concern — concurrency.group at the workflow level couldn't resolve the job-scoped matrix context — is now fixed: concurrency lives under the update job where ${{ matrix.runner }} resolves correctly. Nothing else to flag.

The prerequisite (adding ecs-update-sg / ecs-update-64c labels in GitHub Settings) is clearly documented in the PR body. Approving — the maintainer just needs to add those labels before triggering the first run.

中文说明

置信度：4/5 — 干净、聚焦的 CI 修复，解决了两个实际运维问题；上次审查关于 workflow 层级 concurrency 的顾虑已在本次修订中解决。

这是一个容易审查、六个月后也容易维护的 PR。Diff 只有两个文件 36 行，每项改动都对应所述问题，安装步骤从脆弱的 13 行条件判断（遮蔽 bug 的根因）简化为一行 sudo npm install -g 加清晰的注释。Matrix 策略是 GitHub Actions 多 runner 更新的标准模式，repository_dispatch 钩子是合理的前瞻性补充，在接入前保持惰性。

上次审查唯一的顾虑——workflow 层级的 concurrency.group 无法解析 job 作用域的 matrix 上下文——现已修复：concurrency 放在 update job 下，${{ matrix.runner }} 可以正确解析。没有其他需要指出的问题。

前置条件（在 GitHub Settings 中添加 ecs-update-sg / ecs-update-64c 标签）在 PR 正文中有清晰说明。批准——maintainer 只需在首次触发前添加这些标签。

— Qwen Code · qwen3.8-max-preview

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

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅

[qwen-code-ci-bot]

⚠️ Downgraded from Approve to Comment: CI still running. Reviewed.

— qwen3.7-max via Qwen Code /review

[qwen-code-ci-bot]

⚠️ Downgraded from Approve to Comment: CI still running. Reviewed.

— qwen3.7-max via Qwen Code /review

[github-actions]

Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration.

中文

请勿对活跃的 PR 执行 rebase 或 force-push，因为这会使已有的评审评论失效。另外，供日后参考：作为集成流程的一部分，机器人始终会自动将所有改动压缩（squash）为单个提交。

[qwen-code-ci-bot]

⚠️ Downgraded from Approve to Comment: CI still running. Reviewed.

— qwen3.7-max via Qwen Code /review

[doudouOUC]

Reviewed. Suggestions are inline.

— qwen3.7-max via Qwen Code /review

[qwen-code-ci-bot]

⚠️ Downgraded from Approve to Comment: CI still running. Reviewed.

— qwen3.7-max via Qwen Code /review

[qwen-code-ci-bot]

⚠️ Downgraded from Approve to Comment: CI still running. Reviewed.

— qwen3.7-max via Qwen Code /review

[wenshao]

Review — 5221124

Overview

Fixes the ECS runner updater so it actually updates all runners: a matrix over per-instance labels (ecs-update-sg, ecs-update-64c) with fail-fast: false, unconditional sudo npm install -g so the package lands in /usr/local instead of the runner user's shadowed npm prefix, job-level per-runner concurrency, a repository_dispatch (npm-published) trigger that reads client_payload.version, and the new labels registered in .github/actionlint.yaml.

Verified

• actionlint passes at this head — ran actionlint v1.7.7 against the PR's workflow + config; clean. (Without the actionlint.yaml additions it fails on both new labels, so that part of the change is load-bearing, not cosmetic.)
• Version fallback expression is correct in both trigger paths. Under repository_dispatch the inputs context is empty so inputs.version || github.event.client_payload.version falls through to the payload; under workflow_dispatch with an empty input, '' is falsy and client_payload is null, so INPUT_VERSION ends up empty → resolves to latest. A missing version key in a dispatch payload also degrades to latest rather than erroring.
• Security posture is sound. repository_dispatch requires a write-scoped token and runs the default-branch workflow version, so fork PRs can't reach the sudo step; the github.repository == 'QwenLM/qwen-code' guard is retained; the payload value is passed via env (not interpolated into the script) and is laundered through npm view before anything reaches sudo npm install, so only a real published version of @qwen-code/qwen-code can be installed.
• The Verify step is the real guardrail for the "installed into the wrong prefix" failure mode: qwen --version resolves via the runner user's PATH, so any wrong-place install still fails the job. Good design — the diagnosis in the description doesn't need to be perfect for the workflow to be safe.

Suggestions (minor)

1. Use sudo -n npm install -g …. The old code explicitly checked sudo -n true and emitted a clear ::error when passwordless sudo was missing. Now that path fails with sudo's generic "a terminal is required to read the password". -n (or keeping a tiny sudo -n true || { echo "::error::…"; exit 1; } pre-check) restores a deterministic, self-explanatory failure.
2. Merge/rollout ordering matters more than the description implies. If this merges before the ecs-update-sg/ecs-update-64c labels exist on the runners, any dispatch queues for up to ~24 h waiting for a runner and then fails — and once the follow-up wires release.yml, every publish would produce a stuck run. Worth adding the labels first (it's in the test plan; just flagging the ordering as a hard prerequisite, not a post-merge cleanup item).
3. Superseded pending runs show as "cancelled". Job-level concurrency keeps at most one pending job per group, so two releases in quick succession will mark the middle run cancelled. The final dispatch still converges to the newest version, so behavior is fine — just don't let run-failure monitoring treat those cancellations as regressions.

Pre-existing nit (not introduced here)

npm view "${specifier}" version | tail -n 1: if the specifier is a range matching multiple versions, npm view prints pkg@x.y.z 'x.y.z' lines, so tail -n 1 yields a non-bare-version string; install/verify then fail with a confusing error. Only exact versions/dist-tags behave. Fine to leave, since the input is maintainer-controlled.

Verdict

LGTM. The two fixes match the failure symptoms, the trigger plumbing is safe, and the verify step catches the residual environment unknowns (e.g. root's npm prefix/secure_path on each box). Suggestions above are non-blocking.

中文版

评审 — 5221124

概述

修复 ECS runner 更新工作流,使其能真正更新所有 runner:按实例标签(ecs-update-sg、ecs-update-64c)做 matrix 并 fail-fast: false;无条件 sudo npm install -g,确保安装到 /usr/local 而不是被遮蔽的 runner 用户 npm prefix;job 级按 runner 的 concurrency;新增 repository_dispatch(npm-published)触发并读取 client_payload.version;新标签已注册进 .github/actionlint.yaml。

已验证

• actionlint 通过:用 actionlint v1.7.7 对本 PR head 的 workflow + 配置实测通过;若去掉 actionlint.yaml 的新增项则两个新标签都会报错,说明该改动是必需的。
• 版本回退表达式在两种触发路径下都正确:repository_dispatch 下 inputs 为空,表达式落到 payload;workflow_dispatch 空输入时 '' 为假、client_payload 为 null,最终解析为 latest;dispatch payload 缺 version 键也只会退化为 latest,不会报错。
• 安全性无问题:repository_dispatch 需要 write 权限 token,且只运行默认分支上的 workflow 版本,fork PR 无法触达 sudo 步骤;github.repository 守卫保留;payload 值通过 env 传入(未内插进脚本),且先经 npm view 解析,只有真实已发布的 @qwen-code/qwen-code 版本才会进入 sudo npm install。
• Verify 步骤是真正的兜底:qwen --version 按 runner 用户的 PATH 解析,任何装错位置的情况仍会使 job 失败。

建议(非阻塞)

1. 改用 sudo -n npm install -g …:旧代码在无免密 sudo 时会输出明确的 ::error,现在会变成 sudo 的通用报错("a terminal is required…")。加 -n(或保留一个小的 sudo -n true 前置检查)可恢复确定性的、可自解释的失败信息。
2. 合入顺序是硬性前提:若在给 runner 添加 ecs-update-sg/ecs-update-64c 标签之前合入,dispatch 会排队等 runner 最长约 24 小时后失败;后续 release.yml 接线后,每次发版都会产生一个卡死的 run。应先加标签再合入/接线。
3. 被顶替的排队 run 会显示为 cancelled:job 级 concurrency 每组最多保留一个 pending,连续两次发版会把中间那次标记为 cancelled。最终仍会收敛到最新版本,行为没问题,但监控不要把这类 cancelled 当作故障。

既有小问题(非本 PR 引入)

npm view "${specifier}" version | tail -n 1:若 specifier 是匹配多个版本的 range,npm view 输出 pkg@x.y.z 'x.y.z' 形式的多行,tail -n 1 取到的不是纯版本号,后续 install/verify 会以令人困惑的方式失败。输入由 maintainer 控制,可不改。

结论

**LGTM。**两处修复与故障现象吻合,触发链路安全,Verify 步骤能兜住剩余的环境不确定性(如各机器上 root 的 npm prefix / secure_path 差异)。以上建议均不阻塞。

[wenshao]

@qwen-code /triage

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅

[wenshao]

No issues found. LGTM! ✅

— qwen3.8-max-preview via Qwen Code /review