Repository navigation
objectui: shadcn-check.yml 用 continue-on-error 吞掉 shadcn:check 的退出码,该周期任务无法对任何失败告警 #5805
Description
发现于 objectstack#5505 / objectui PR #3455 的实施过程,单独记录。
现象
.github/workflows/shadcn-check.yml 里跑 pnpm shadcn:check 的那一步带 continue-on-error: true:
- name: Check component status (online)
id: check
run: |
echo "Checking component status against Shadcn registry..."
pnpm shadcn:check > check.txt
cat check.txt
continue-on-error: true该 workflow 只在 schedule(每周一)和 workflow_dispatch 触发,不在 PR 上跑;而这一步无论退出码是什么都算通过。因此这个任务在任何情况下都不会把 job 标红,只会上传一份 artifact 等人主动去看。
为什么现在值得重看
在 PR #3455 之前 shadcn:check 永远退出 0(它纯粹是状态报告),continue-on-error 是合理的。该 PR 给它加了真实的失败语义:当已声明的本地补丁从磁盘文件里丢失、或已无法重新施加到当前上游时,以非零码退出。这是第一次 shadcn:check 的退出码承载信息 —— 而这个 workflow 恰好把它丢掉。
需要说明:PR #3455 的 PR 级闸门并不依赖这个 workflow,而是 scripts/__tests__/shadcn-local-patches.test.ts(纯离线,在 ci.yml 里跑),所以补丁不变量本身是被守住的。这里缺的是另一半:上游挪了锚点导致"下次同步会失败"的提前预警 —— 那一条需要联网访问 registry,只有这个周期任务在跑,而它现在无法告警。
影响
上游 shadcn 改动了 Sheet/Dialog 关闭按钮结构的那一周,唯一能提前发现的信号会被静默吞掉,直到有人手动去翻 artifact 或直到有人真的跑 --update 撞上拒绝写入。
建议方向
需要区分两类失败,不宜简单把 continue-on-error 去掉:
- registry 不可达 / 网络问题 → 应继续容忍(这正是当初加
continue-on-error的原因); - 已声明补丁失效(退出码 1)→ 应让 job 失败,或至少自动开 issue。
该 workflow 后半段已经有"发现更新就开 issue"的逻辑(用 labels: ['maintenance', 'shadcn-sync', 'dependencies']),把补丁失效接进同一条路径可能比让 job 红更合适 —— 请 PM 定夺。
Activity
yinlianghui commentedon Aug 6, 2026
认领:objectui 分片 PM 并行批第 58 单
会话:
session_01GTRjn8xBqp75dk7kFupVRt分支:
claude/issue-5805-shadcn-check-exitcode(落地仓 objectui)Worktree:
objectui-issue-5805文件面:
.github/workflows/shadcn-check.yml。PM 裁定(issue 交定夺的两分法):采 issue 后段建议——接进既有开-issue 路径而非让 job 红:退出码区分两类失败(registry 不可达继续容忍;已声明补丁失效→自动开 issue,复用该 workflow 现有的 create-issue 逻辑与标签)。理由:周任务红没人看,issue 才进分诊流;这也要求 #5803 的状态码检查先行或同批(否则网络错误与补丁失效在退出码上不可分)——与第 57 单同批恰好成立,若需依赖其产出请在报告中说明串行需求。
Generated by Claude Code
yinlianghui commentedon Aug 6, 2026
验收:ACCEPT → objectui PR #3497(并行批第 58 单,会话
session_01GTRjn8xBqp75dk7kFupVRt),已跑检查零失败(workflow-only 改动)。ready + auto-merge 因 GraphQL 配额排队,恢复即执行。复核要点:前提复核发现比 issue 更深一层——
if: failure()遇上被容忍的步骤永不为真,开-issue 块自诞生起从未执行过一次(label 检索零命中佐证);裁定(接开-issue 路径、job 不红)落地为三类分流:patch 失效→告警(复用原块与标签)、registry 不可达→容忍但 ::warning:: + step summary(绿勾不再冒充健康证明)、意外非零→独立告警(不再有可坠落的缝);唯一会红的是「告警本身投递失败」——正确的反转。5/5 夹具干跑方向全中,与在飞 #5803 的独立性经读其分支核实。PM 承诺项:合并后手动 workflow_dispatch 一次,端到端验证告警通道与 token 建 issue 权限(该路径从未真实跑过)——已记入任务清单。三条 deliberately-unfixed 披露(连续不可达周的跨 run 告警、timeout-minutes 缺失、analyze 步的静默崩溃)由 PM 承接,待配额恢复查重后立单;dev 对 #5803 worktree 的中写快照观察已顺带提醒该单自查。Generated by Claude Code