ci(triage): surface live progress via an early status comment - #7654
Conversation
`@qwen-code /triage` runs the agent as one long workflow step, so the PR thread stays silent until the first stage comment lands — the maintainer can't tell it started or how far along it is. The agent's output already streams live to the Actions log; the run link was only surfaced at the end. Post a `stage=status` comment up front carrying that live run link, and finalize the same comment (by marker, so a re-run reuses one comment) to a terminal state at the end. Covers manual, auto (pull_request_target), and dispatch triage. Best-effort — a failed status post never fails triage.
|
@qwen-code /takeover |
|
🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. Remove the 中文说明🤝 已接管:autofix 循环现在管理此 PR —— 将持续处理新的评审反馈与 base 冲突,直到移除标签或达到轮次上限。移除 |
|
Thanks for the PR! Template looks good ✓ — all required sections present with bilingual translation. Problem: this is an observed usability gap, not a theoretical one. Today the triage agent runs as a single long workflow step and the PR thread stays silent until the first stage comment lands. On Direction: aligned — this is a straightforward CI observability improvement for maintainers, within the project's infrastructure scope. Doesn't touch auth, sandbox, model selection, or any public contract. Follow-up to the triage-verification work in #7648. Size: not applicable — no core paths touched. Changes are confined to Approach: the scope feels right. Two small workflow steps (post + finalize) that surface the existing live log link early, upsert by marker to avoid comment stacking, and best-effort so a failed status post never breaks triage. The PR explicitly explains what was deliberately not done (agent-maintained per-stage status line) and why — good scoping discipline. No unrelated changes or drive-by refactors in the diff. Moving on to code review. 🔍 中文说明感谢贡献! 模板完整 ✓ —— 所有必需章节齐全,附中文翻译。 问题:这是一个已观测到的可用性缺口,而非理论性问题。目前 triage agent 作为单个长 workflow step 运行,PR 线程在首个 stage 评论落地前一直静默。 方向:对齐 —— 这是一个直接的 CI 可观测性改进,面向维护者,在项目基础设施范围内。不涉及 auth、sandbox、模型选择或任何公共契约。是 #7648 triage 验证工作的跟进。 规模:不适用 —— 未触及核心路径。改动仅限于 方案:范围合理。两个小 workflow step(发布 + 定稿),尽早露出已有的实时日志链接,按 marker upsert 避免评论堆叠,尽力而为所以状态评论失败不会拖垮 triage。PR 明确说明了特意没做什么(agent 维护的逐阶段状态行)及原因 —— 范围把控得当。diff 中无无关改动或顺手重构。 进入代码审查 🔍 — Qwen Code · qwen3.8-max-preview Reviewed at |
Code ReviewIndependent proposal: for "surface live triage progress early", I'd add a workflow step right after the number resolves that posts a comment with the Actions run URL, using a marker for upsert so re-runs don't stack. Then a finalize step at the end ( Comparison with the diff: the implementation matches the straightforward approach — no over-engineering, no missed simpler path. A few specifics:
No critical blockers. No AGENTS.md violations. TestingThis is a CI workflow change ( shellcheck was not available in this environment; the PR author reports shellcheck 0.11.0 clean on both run blocks. 中文说明代码审查独立方案: 要"尽早露出 triage 实时进度",我会在 number 解析后加一个 workflow step,发一条带 Actions 运行 URL 的评论,用 marker 做 upsert 避免 re-run 堆叠。最后加一个定稿 step( 与 diff 对比: 实现与直接方案一致——没有过度设计,也没有遗漏更简路径。几个具体点:
无关键阻塞。无 AGENTS.md 违规。 测试这是 CI workflow 改动(
— Qwen Code · qwen3.8-max-preview Reviewed at |
|
Confidence: 5/5 — clean, focused CI improvement that solves a real observability gap with the minimum viable change. This is what a good small PR looks like. The problem is concrete (triage runs silently until the first stage comment lands, and The diff is additions-only across two files, the new test pins the behaviors that matter, and everything passes. If I had to maintain this in six months, I'd thank the author — the comments explain the why, the code is self-evident, and there's nothing to untangle. LGTM, approving. ✅ 中文说明置信度:5/5 —— 干净、聚焦的 CI 改进,用最小可行改动解决了真实的可观测性缺口。 这是一个优秀的小型 PR 该有的样子。问题具体(triage 运行时在首个 stage 评论落地前一直静默, diff 纯新增,跨两个文件,新测试固定了关键行为,全部通过。如果半年后我来维护这个,我会感谢作者——注释解释了为什么,代码不言自明,没有什么需要解开的。 LGTM,批准。✅ — Qwen Code · qwen3.8-max-preview Reviewed at |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
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. |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed diff-only — the PR’s existing discussion could not be fetched, so this is not an approval and not a no-blockers claim. 1 Suggestion-level finding(s) could not be anchored to a changed line and were dropped; nothing further to act on here. Not reviewed: issue-fidelity — pr-context failed (gh CLI not authenticated); scope could not be determined. Not reviewed: Agent 0: Issue fidelity & root-cause ownership — its prompt was built, but no agent on record was launched with it.
— qwen3.7-max via Qwen Code /review
| if: "steps.resolve.outputs.number != ''" | ||
| shell: 'bash' | ||
| env: | ||
| GH_TOKEN: '${{ secrets.QWEN_CODE_BOT_TOKEN || secrets.CI_BOT_PAT }}' |
There was a problem hiding this comment.
[Suggestion] The jq -rs '[.[][] | select(.body | contains($m))] | last | .id // empty' pagination approach flattens all pages into one array. For PRs with thousands of comments this could be slow, but triage PRs rarely accumulate that many comments — acceptable trade-off.
— qwen3.8-max-preview via Qwen Code /review
yiliang114
left a comment
There was a problem hiding this comment.
LGTM. Clean two-step progress mechanism — early status comment with live run link, finalized on both success and failure. Marker-based upsert prevents re-run clutter. Best-effort throughout. One inline nit on jq pagination for high-comment PRs.
— qwen3.8-max-preview via Qwen Code /review
What this PR does
Gives
@qwen-code /triagean early, in-thread progress signal. The moment triage starts it posts a status comment carrying a link to the live Actions run, and finalizes that same comment when the run ends.Why
Triage runs the agent as one long workflow step. Today the only immediate acknowledgement is a 👀 reaction (and only on comment triggers) — after that the PR thread is silent until the first stage comment lands (agent boot → Stage 1 → the long Stage 2 code-review + tmux testing). A maintainer can't tell whether it started or how far along it is. The agent's output already streams live to the Actions log, but that run link was only surfaced at the very end (in one silent-re-run edge case), so nobody could watch during the run.
pull_request_targetauto-triage had no acknowledgement at all.The fix is to surface the existing live log early — the Actions log is far more granular (every tool call, every
capture-pane, the model's reasoning) than any status text we could synthesize.How
Two small workflow steps in the
triagejob, no agent/skill dependency:Post triage status comment(right after the number resolves, before the agent) — posts<!-- qwen-triage stage=status -->→🔄 Qwen Triage is running — [watch live progress](run). Covers manual,pull_request_target, andworkflow_dispatchtriage.Finalize triage status comment(success() || failure()) — edits the same comment to a terminal✅ finished/⚠️ ended early(fromsteps.triage.outcome), keeping the run link. Neutral wording — the verdict lives in the stage comments.Both upsert by marker, so a re-run reuses the one comment (no clutter/stacking), and both are best-effort (
set -uo pipefail+ warn-and-continue) — a failed status post never fails triage.Deliberately not done: an agent-maintained per-stage status line. It would be less reliable exactly where it's most needed (mid-Stage-2, when the agent is busy), cost agent turns, and risk drift from the real stage comments — and the live log already does that job better. If the live link doesn't close the Stage-2 gap, a targeted "posting Stage 2b test now" line is the cheaper next step.
Reviewer Test Plan
scripts/tests/qwen-triage-workflow.test.js— 13 passed (adds one test pinning: early status carries therun_idlink + marker; both steps upsert via--method PATCH; best-effort). Mutation-verified: removingwatch live progress, or breaking the finalizePATCH, turns exactly that test red.quote-type: single, allow-quoted-quotes) — clean (theif:values are double-quoted only because they contain'').bash -n— clean.SC2016note at line ~1009 (publish-tmux) is untouched.Risk & Scope
Linked Issues
Follow-up to the triage-verification work (#7648) — same goal of making
/triagelegible to maintainers, here for progress rather than evidence depth.中文说明
本 PR 做了什么
给
@qwen-code /triage一个早期、线程内的进度信号:triage 一开始就发一条带实时 Actions 运行链接的状态评论,运行结束时把同一条评论定稿。为什么
triage 把 agent 跑在单个 workflow step 里。现在唯一的即时反馈是 👀 reaction(还仅限评论触发),之后 PR 线程一直静默,直到首个 stage 评论落地(agent 启动 → Stage 1 → 最长的 Stage 2 代码评审+tmux 测试)。维护者看不出它开没开、跑到哪。agent 输出本就实时流进 Actions 日志,但那个运行链接只在最后(某个静默 re-run 边角分支)才露出,运行中没人能看;
pull_request_target自动 triage 更是完全没有任何反馈。修法是把已有的实时日志早点露出来 —— Actions 日志的粒度(每个工具调用、每次
capture-pane、模型推理)远比我们能拼出的状态文本细。怎么做
triagejob 里两个小步骤,不依赖 agent/skill:Post triage status comment(number 解析后、agent 之前)—— 发<!-- qwen-triage stage=status -->→🔄 正在运行 — [查看实时进度](run)。覆盖手动、pull_request_target、workflow_dispatch。Finalize triage status comment(success() || failure())—— 把同一条评论改为终态✅ 已完成/⚠️ 提前结束(依据steps.triage.outcome),保留运行链接。措辞中性 —— 裁决在各阶段评论里。两者都按 marker upsert,re-run 复用同一条评论(不刷屏/不堆叠);都是尽力而为(
set -uo pipefail+ 告警后继续)—— 状态评论失败绝不拖垮 triage。**特意没做:**由 agent 维护的逐阶段状态行。它在最需要的地方(Stage 2 中段、agent 正忙时)最不可靠,耗 agent turn,还会和真实 stage 评论漂移 —— 而实时日志已经把这活干得更好。若实时链接堵不住 Stage 2 那段空窗,更便宜的下一步是一行靶向的"正在测 Stage 2b"。
评审验证
qwen-triage-workflow.test.js—— 13 通过(新增一条:早期状态带run_id链接+marker;两步都用--method PATCHupsert;尽力而为)。变异验证:删watch live progress或破坏 finalize 的PATCH,恰好该测试变红。quote-type: single, allow-quoted-quotes)—— 干净(if:用双引号仅因含'')。bash -n—— 干净。publish-tmux)预存的SC2016未触碰。风险与范围
关联 Issue
triage 验证工作(#7648)的跟进 —— 同样是让
/triage对维护者更透明,这次针对进度而非证据深度。