跳到主要内容

流水线为什么没跑 / 为什么被杀了

这篇解决两类问题：没跑起来，和跑到一半被杀了。

一、没跑起来：按顺序查五步​

官方 FAQ 给的排查顺序，照着走一遍基本能定位：

  1. 代码真的 push 到远端了吗——git log origin/main 看一眼
  2. 对应分支有 .cnb.yml 吗——注意是"对应分支"，不是默认分支
  3. 配置语法对吗——YAML 缩进错、include 的文件没权限，都会静默不跑
  4. 声明了当前分支的当前事件吗——你在 pull_request 里等 push 当然是空的
  5. 命中 skip 检测了吗——[ci skip]、密钥仓库变更、未勾选自动触发

:::tip 最快的入口 云原生构建 → 历史事件，没触发的事件不可点，但鼠标悬停会直接告诉你原因。这一步比人肉排查快十倍。 :::

二、几个特别隐蔽的坑​

默认分支不一定是 main

从其他平台迁移的仓库，默认分支可能是 master。issue.*、tag_push 之外的一些事件读的是默认分支的配置，写错就白配。

评论数超过 100 条后，@NPC 不再触发

issue.comment / pull_request.comment / @npc 事件在评论数 > 100 时全部不再触发流水线。老 Issue 里 @ 机器人没反应，多半是这个。

同一分支下有多条 glob 都匹配

它们会并发执行，不是取第一个。你可能收到多份构建结果。

改了 title / description 触发的是 pull_request.update

pull_request 不含标题描述修改。想覆盖全部变更用 .update。

三、被杀了：超时规则​

层级默认限制
流水线整体最长 20 小时，超时容器销毁
单个任务（Job）无输出连续 10 分钟无输出即超时
单个任务最大执行默认 2 小时，最多可调到 12 小时

自己声明 timeout 可以同时改"无输出超时"和"最大执行时间"：

.cnb.yml
main:
  push:
    - stages:
        - name: build
          image: node:20
          script: |
            npm install
            npm run build
          timeout: 30m

写了 timeout: 30m 之后：连续 30 分钟无输出才超时（替代默认 10 分钟），最长执行 30 分钟。单位支持 ms、s、m、h。

:::warning 无输出超时是最常见的“假死” 很多卡死的任务其实是被"10 分钟无输出"杀的。长任务记得定期打印进度，或者直接调大 timeout。 :::

四、失败时做兜底​

.cnb.yml
main:
  pull_request:
    - stages:
        - name: lint
          script: npm run lint
        - name: test
          script: npm test
      failStages:
        - name: notify
          script: echo "检查失败"

failStages 在任一 stage 失败后执行，适合发通知、归档现场日志。

五、本地好 CI 不好：登进容器看​

这是 CI 环境不一致的经典问题。CNB 提供了「登录调试」：

  • 构建过程中：日志页直接点「登录调试」
  • 构建结束后：日志页勾选 Debug，点 Rebuild，新构建结束后环境保留 5 分钟供你登入

系统会定时检测登录状态：无人登录就销毁，有人登录就续命，最长 1 小时。

更精准的用法是只重跑可疑的那一段——Rebuild 时勾选具体 Pipeline / Stage / Job，再登进去核对产物（比如 node_modules 和本地是否一致）。

:::tip 注意前置依赖 只勾选后面的 Stage 时，如果它依赖前面的产物，会因为缺产物而失败。按需把前置任务一起勾上。 :::

六、构建日志、耗时怎么用​

  • 失败先看第一个报错的 stage，后面的错误往往是被连带的
  • 耗时排行看每个 stage 的耗时条，优化要打最长的那个
  • 构建历史可以下载，方便贴给别人看