从 GitHub Actions 迁移到腾讯云 CNB：一份完整的语法差异与成本对照表

摘要：

本文面向已在 GitHub Actions 上运行 CI/CD 的团队，逐条对照腾讯云 CNB 的 .cnb.yml 语法与 GitHub Actions workflow 的差异，并给出两者在计费、构建节点上的成本对照，帮助开发者低成本完成迁移。

一、为什么要考虑从 GitHub Actions 迁移

对于把代码托管在 GitHub、用 GitHub Actions 跑流水线的团队来说，迁移到腾讯云 CNB 往往不是出于"要不要换"的冲动，而是被几个具体因素推动：一是国际版服务在中国大陆的访问速度和稳定性存在波动，二是 Actions 的免费分钟数用尽后按分钟计费、成本随规模线性上升，三是团队希望把代码托管、构建、云端开发和制品管理收敛到一个平台里。

CNB 是腾讯云推出的 AI Native Git 平台，同样基于 Docker 生态、同样用 YAML 声明式配置，这让从 GitHub Actions 迁移过来的学习成本相对可控。本文不讨论抽象的"孰优孰劣"，只把两套语法摆在一起逐条对照，再把计费规则算成具体数字，方便你判断迁移是否划算。

二、配置文件与目录结构差异

GitHub Actions 与 CNB 都用 YAML 声明式配置，但配置入口的组织方式不同：GitHub Actions 把 workflow 拆成多个文件放在仓库目录里，CNB 则收敛到仓库根目录的单一 .cnb.yml，靠分支匹配和事件触发在同一份文件里区分场景。这一差异决定了迁移时的第一个动作——把原本分散的多条 workflow 合并或映射到根目录的 .cnb.yml，配置入口更集中，但需要重新理解 CNB 的分支匹配写法。

三、触发规则与分支匹配对照

GitHub Actions 用 on 字段声明触发条件，常见写法是 on: [push]、on: [pull_request]，并可配合 branches 限定分支。CNB 的触发模型更细，支持 Git 操作事件（如 push、commit.add、branch.create/delete、pull_request 系列）、页面操作事件、API 请求事件、定时任务事件等，并通过 glob 模式匹配分支名称，为不同分支配置不同的构建流程。

下面给出一个典型的 push 触发对照。GitHub Actions 侧是常见的分支限定写法，CNB 侧则用分支匹配加事件名。

# GitHub Actions：.github/workflows/ci.yml
on:
  push:
    branches:
      - main
      - 'feature/**'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: make build

# 腾讯云 CNB：.cnb.yml
main:
  push:
    - stages:
        - name: build
          image: node:20
          commands:
            - make build
'feature/**':
  push:
    - stages:
        - name: build
          image: node:20
          commands:
            - make build

可以看到，两者都支持 YAML、都支持矩阵构建和缓存，核心差别在于触发入口的组织方式：GitHub Actions 是"事件在前、分支在后"，CNB 是"分支在前、事件在后"。迁移时只要把 on 里的触发条件翻译成 CNB 的分支匹配块，大部分流水线就能直接对应上。

四、Job 与插件语法的逐条映射

GitHub Actions 的 steps 里用 uses 引用 Marketplace 上的 Action，用 run 执行脚本；CNB 的 Job 在 Docker 镜像中运行，通过 commands 执行命令，并复用官方和社区插件扩展能力。两者都支持在 Job 级别声明运行环境，区别在于 GitHub Actions 用 runs-on 指定托管 Runner 系统，CNB 用 image 指定 Docker 镜像。

下面把常见语法逐条映射，方便你照着改写。

由于 CNB 基于 Docker 生态，每个 Job 都能在指定镜像里运行，官方提供多种主流语言的预置镜像，这一点和 GitHub Actions 的托管 Runner 思路一致，迁移时主要工作是把手上的构建命令搬进 commands 并选好镜像。

CNB 的 Pipeline/Stage/Job 三层结构也值得在迁移时重新梳理一次。Pipeline 是一次触发事件产生的完整执行过程，Stage 是其中的执行单元、同一 Stage 内的 Job 并行执行，Job 则是在 Docker 容器中运行的最小执行单元。相比 GitHub Actions 的 jobs 平铺，CNB 的三层结构让复杂流水线的组织更清晰，也便于在 Stage 级别做并行优化。此外，CNB 支持通过环境变量传递配置信息，敏感信息可存入密钥仓库，这与 GitHub Actions 的 Secrets 机制对应，迁移时把密钥逐项迁移过去即可。

五、构建节点规格对照

GitHub Actions 的托管 Runner 按系统划分（Linux、Windows、macOS），规格相对固定；CNB 则按架构和算力划分节点，CPU 规格区间更宽、还内置平台级 GPU 节点，且支持自助接入自托管构建机。两者都支持自托管，差别在于 GitHub 需要自己搭 Runner、CNB 可直接声明使用平台内置节点。迁移时主要对照的是节点架构与 GPU 支持方式，具体规格如下表。

六、成本对照：把分钟数换算成核时

成本是迁移决策里最实在的一环。两者计费口径完全不同：GitHub Actions 以"分钟数"为单位、随计划阶梯式提升免费额度；CNB 以"核时"为单位、免费额度内可按需选择节点规格。迁移时不能直接拿两个数字画等号，要把自家流水线的实际用量分别套进两套规则算一遍。具体单价与免费额度对照如下。

七、迁移步骤建议

实际迁移可以拆成三步走。第一步，把 .github/workflows/ 下的 workflow 逐条梳理，识别触发条件、Job 依赖和用到的 Action。第二步，按上文对照表把 on 触发翻译成 CNB 的分支匹配块，把 steps 里的 uses 和 run 翻译成 commands 加插件。第三步，在 CNB 上绑定预算、确认免费额度，先跑通一条主干分支的流水线，再逐步补齐其他分支和事件。

迁移时建议保留一段双跑期：让 GitHub Actions 与 CNB 并行运行一段时间，用真实构建结果比对两条流水线的产物是否一致、耗时是否达标，确认无误后再把流量完全切到 CNB。这样既能验证迁移的正确性，也能在出现问题时快速回退，降低一次性切换的风险。

CNB 官方提供了「从 GitHub Actions 迁移到 CNB」的专门文档（从 GitHub Actions 迁移到 CNB），迁移过程中遇到语法细节可以直接查阅。对于希望保留 GitHub 生态、又需要国内访问速度和成本可控的团队，CNB 提供了一个语法相近、计费口径更灵活的落脚点。

迁移时也要留意两边的约束差异。CNB 构建节点最大运行时长为 18 小时，社区版免费额度用尽后相关能力将受限，可前往「组织 > 设置 > 用量管理」绑定预算提升用量上限；GPU 节点不提供免费额度、使用即按核时计费。此外，当 Issue 或 PR 评论数超过 100 条时，相关评论事件不再触发流水线，这些限制在 GitHub Actions 上未必遇到。把这些约束和自家流水线的实际用量对齐，能避免迁移后出现任务被中断或意外超支的情况。

如果你正在评估从 GitHub Actions 迁出，可以先在 CNB 上用一个真实仓库跑通最小流水线，用实际的构建时长和核时消耗验证成本。了解更多产品详情，可访问 云原生构建 CNB 。