CNB API 触发流水线

API 触发本质是通过在 .cnb.yml 中定义 api_trigger 类事件规则，并通过平台内置任务（cnb:apply/cnb:trigger）触发流水线，以下提供两个最常用场景的完整流水线示例（同仓库触发、跨仓库触发），均基于官方配置规范编写，可直接复用修改：

官方文档

场景 1：同仓库 API 触发

自身流水线触发自身子任务，适用于当前仓库内的流程联动（如 “代码提交后，触发 API 子流水线执行测试 / 打包”），核心用 cnb:apply 内置任务，无需跨仓库权限。

# 仓库：my-project（当前操作仓库）
# 功能：main 分支代码 push 后，先执行主构建，再通过 API 触发子流水线做测试验证

# 1. 主触发事件：main 分支的 push 事件（代码提交时触发主流水线）
main:
  push:
    - stages:
        # 阶段1：主流水线的基础构建任务
        - name: "主流水线-代码构建"
          script: |
            echo "主流水线：开始构建代码（$(date)）"
            echo "主流水线：代码构建完成"

        # 阶段2：API 触发子流水线（核心步骤，用 cnb:apply 内置任务）
        - name: "API触发-子流水线（测试验证）"
          type: cnb:apply  # 官方内置任务：同仓库 API 触发
          options:
            # 关键：指定子流水线的 API 事件名（必须是 api_trigger 或 api_trigger_xxx）
            event: api_trigger_test
            # 同步模式：true=等待子流水线完成后再继续主流水线，false=异步触发
            sync: true
            # 子流水线失败时，主流水线是否终止（false=终止，true=继续）
            continueOnBuildError: false
            # 子流水线的自定义标题（便于在平台上区分日志）
            title: "子流水线-测试环境验证"
        - name: "主流水线-结束"
          script: |
            echo "主流水线：结束"

  # 2. API 子流水线规则：响应 api_trigger_test 事件（被阶段2触发）
  api_trigger_test:
    - stages:
        - name: "子流水线-测试环境准备"
          script: |
            echo "子流水线：测试环境准备（环境=，版本=）"

触发逻辑与验证

触发方式：向 my-project 仓库的 main 分支提交代码（如 git push origin main），主流水线会自动启动。
执行流程：主流水线先完成 “代码构建”→ 触发 api_trigger_test 子流水线→ 子流水线完成 “测试准备 + 自动化测试”→ 主流水线汇总结果。
验证路径：登录 CNB 平台 → 进入 my-project 仓库 → 查看 “流水线记录”，可同时看到 “主流水线” 和 “子流水线” 的执行日志，子流水线标题为配置中的 “子流水线 – 测试环境验证”。

场景 2：跨仓库 API 触发

A 仓库触发 B 仓库流水线，适用于跨仓库联动（如 “A 仓库构建完成后，触发 B 仓库的部署流水线”），核心用 cnb:trigger 内置任务，需提前准备 “B 仓库权限” 和 “个人访问令牌”。

前置准备（跨仓库触发必需）

权限配置：确保当前操作账号（配置令牌的账号）拥有 B 仓库的 “触发流水线” 权限（在 B 仓库 “设置→成员管理” 中添加账号，权限设为 “开发者” 及以上）。
获取个人访问令牌：登录 CNB 平台 → 右上角头像→“个人设置”→“API 凭证”→“生成令牌”→ 复制令牌（记为 CNB_TOKEN，后续配置用）。

仓库 A 的 .cnb.yml

# 仓库A：projectA（当前操作仓库，负责构建）
# 仓库B：projectB（目标仓库，负责部署）
# 功能：仓库A的 main 分支构建完成后，API 触发仓库B的部署流水线，将版本部署到测试环境

# 1. 主触发事件：仓库A main 分支的 push 事件
main:  
  push:
    - stages:
        # 阶段1：仓库A自身的构建任务
        - name: "仓库A-构建打包"
          script: |
            echo "仓库A：构建 main 分支代码（$(date)）"
            # 打包构建结果（用于后续部署）
            echo "仓库A：构建完成，CommitID：${CNB_COMMIT:0:8}"  # 取Commit前8位

        # 阶段2：跨仓库 API 触发（核心步骤，用 cnb:trigger 内置任务）
        - name: "API触发-仓库B部署流水线"
          type: cnb:trigger  # 官方内置任务：跨仓库 API 触发
          options:
            # 关键1：目标仓库（仓库B）的完整路径（组织名/仓库名，必填）
            slug: ryan/projectB
            # 关键2：个人访问令牌（必填，用环境变量注入，避免硬编码）
            token: *********
            # 关键3：仓库B的 API 事件名（需在仓库B的 .cnb.yml 中定义）
            event: api_trigger_deploy_dev
            # 仓库B的触发分支（默认主分支，可指定）
            branch: main
            # 同步模式：等待仓库B流水线完成后再继续
            sync: true
         
        # 阶段3：结果通知
        - name: "跨仓库触发结果"
          script: |
            echo "======================================"
            echo "仓库A：跨仓库触发完成"
            echo "仓库B流水线号"
            echo "仓库B部署日志："
            echo "部署环境："
            echo "来源Commit："
            echo "======================================"

仓库 B 的 .cnb.yml

main:
  # 响应跨仓库触发的 API 事件
  api_trigger_deploy_dev:
    - stages:
        - name: "仓库B-执行部署"
          script: |
            echo "仓库B：部署到环境"
            # 模拟部署命令（实际需替换为项目真实部署脚本，如 kubectl、ansible 等）
            echo "仓库B：部署成功！"

触发逻辑与验证

触发方式：向仓库 A 的 main 分支提交代码，仓库 A 主流水线启动。
执行流程：仓库 A 完成构建→ 触发仓库 B 的 api_trigger_deploy_dev 流水线→ 仓库 B 部署→ 仓库 A 汇总结果。
验证路径：
- 仓库 A：查看流水线记录，阶段 2 会显示 “触发仓库 B 流水线成功”，并附带仓库 B 的日志链接。
- 仓库 B：查看流水线记录，会新增一条 “api_trigger_deploy_dev” 事件的流水线，标题默认包含 “来自 projectA 的触发”。

核心配置要点（避免踩坑）

事件名必须合规：子流水线 / 目标仓库的事件名必须是 api_trigger 或 api_trigger_xxx（如 api_trigger_test/api_trigger_deploy_dev），否则无法被 API 触发识别。
跨仓库触发的令牌权限：token 必须对应拥有目标仓库权限的账号，且建议通过 “环境变量注入”（如 $CNB_TOKEN），不要在 .cnb.yml 中硬编码（避免泄露）。
同步 / 异步控制：sync: true 适合需要等待结果的场景（如测试不通过则终止主流程），sync: false 适合无需等待的场景（如异步通知）。
参数传递：通过 params（同仓库）或 env（跨仓库）传递的变量，在子流水线中可直接用 $变量名 引用（如 $TEST_ENV/$DEPLOY_ENV）。