开发者推送代码——一个容器随即启动并开始运行测试。如果您使用的是 GitHub，这个运行器（runner）会执行一系列从公共市场获取的 JavaScript 或 Docker 操作（actions）。如果您使用的是 GitLab，一个基于 Go 语言的单一二进制文件会通过原生关键字来执行高度结构化的 YAML 文件。
尽管您的团队可能已经选定了 Git 托管平台，但 GitHub 和 GitLab 的 CI 层在底层架构哲学上有着本质的不同。要决定如何运行构建、管理运行器以及保护密钥安全，我们需要仔细审视这些底层引擎。
核心架构差异
GitHub Actions 和 GitLab CI 从模块化光谱的两端来审视流水线的执行。
GitHub Actions 具有高度的可组合性。它依赖于逐步执行的模型，其中单个步骤可以运行社区编写的 action。这些 action 本质上是用 JavaScript 编写或打包为 Docker 容器的封装代码库。这使得该平台具有极强的扩展性——但同时也给您的构建过程引入了外部依赖。
GitLab CI 则依赖于集中式、高度结构化的 YAML 配置。它不需要从市场中拉取第三方任务，而是让您使用强大的内置关键字（如 rules、needs 和 stages）来定义和编排任务。这种设计优先考虑了可预测性和控制力——将整个流水线定义完全保留在您自己的代码库边界内。
Runner 管理与自托管
在托管基础设施上运行构建的成本会迅速增加。对于重度工作负载，团队通常会选择管理自己的构建代理（agents）。
GitHub 使用一个用 .NET Core 编写的自托管 runner 应用程序。虽然它支持主流操作系统，但编排大规模的 runner 集群通常需要第三方工具。例如，为了在 Kubernetes 上自动缩放 GitHub runner，许多平台团队依赖于社区驱动的 Actions Runner Controller (ARC)。
GitLab Runner 是一个基于 Go 的单一二进制文件。它拥有成熟的内置执行器（executor）模型。开箱即用，GitLab Runner 原生支持多种执行器，包括：
- Kubernetes（为每个任务生成一个新的 Pod）
- Docker（在隔离的容器中运行任务）
- VirtualBox 或 Parallels（用于干净的虚拟机环境）
- Shell（在主机上直接执行）
对于复杂的企业基础设施，GitLab 的原生自动缩放配置通常更容易设置和维护，无需依赖外部的开源控制器。
流水线语法与配置复杂度
这两个平台都使用 YAML，但它们处理复杂工作流的方式不同。
GitHub Actions 使用可重用工作流（reusable workflows）和复合操作（composite actions）来减少重复。复合操作允许您将多个步骤打包成一个可重用的步骤，而可重用工作流则允许您在不同的代码库之间共享整个流水线模板。
GitLab CI 使用基于 extends 和 includes 的继承模型。这允许平台团队编写一个主流水线模板，并将其引入到数百个项目中。然后，开发者可以根据需要覆盖特定的参数。
实例演示：矩阵构建
假设您需要在多个 Node.js 版本和数据库引擎上运行集成测试。
在 GitHub Actions 中，您直接在任务配置中定义矩阵策略：
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [16, 18, 20]
database: [postgres, mysql]
steps:
- uses: actions/checkout@v4
- name: Use Node.js
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- run: npm ci
- run: npm test
在 GitLab CI 中，您可以使用 parallel:matrix 关键字来实现这一点：
test:
image: node:$NODE_VERSION
services:
- name: $DATABASE_IMAGE
parallel:
matrix:
- NODE_VERSION: ["16", "18", "20"]
DATABASE_IMAGE: ["postgres:15", "mysql:8"]
script:
- npm ci
- npm test
这两种方法达到了相同的效果：运行 6 个并行的测试任务。然而，GitHub Actions 依赖于市场中的 action（actions/setup-node）来配置环境，而 GitLab CI 则要求您直接定义基础 Docker 镜像。
生态系统、市场与扩展性
这里的选择取决于您更倾向于单一供应商提供的精选平台，还是社区驱动的生态系统。
GitHub 的市场包含数千个预构建的 action。如果您需要发送 Slack 通知、将构建产物上传到 AWS，或者运行安全扫描，很可能已经存在一个现成的 action。这加快了初始流水线的创建速度。然而，依赖社区 action 意味着您必须信任上游维护者——或者将每个 action 锁定到特定的提交 SHA，以防止供应链攻击。
GitLab CI 避开了市场模型。相反，GitLab 将常用功能直接内置到平台中。安全扫描、容器镜像库管理和发布跟踪都是原生功能。这减少了您对第三方代码的依赖，但这也意味着如果 GitLab 原生不支持某个特定工具，您必须编写自定义的 Shell 或容器步骤。
如果您的团队想要评估这些生态系统如何融入更广泛的工具链，读者可以在 StackMatch 上探索更多选择。
安全与密钥管理
这两个平台都支持现代的 OpenID Connect (OIDC) 联合凭证。这允许您的流水线与 AWS、GCP 或 Azure 等云服务商进行身份验证，而无需在 CI 配置中存储长期访问密钥。
GitHub 通过允许您将密钥限制在特定的分支或部署环境中来确保环境安全。您还可以在运行部署任务之前要求进行手动审批。
GitLab 提供了类似的特定环境保护，但与 HashiCorp Vault 进行了更紧密的原生集成。它还在其核心平台中提供了内置的密钥检测功能——在构建完成之前就会扫描您的代码，以防止意外提交 API 密钥。
做出选择：何时使用哪一个
您对 CI 引擎的选择应该与您团队的运作风格相匹配：
- 选择 GitHub Actions：如果您的团队注重速度，严重依赖公共开源工具，并且相比编写自定义脚本更喜欢使用预构建的组件。对于能从庞大社区生态中受益的项目，这是自然而然的选择。
- 选择 GitLab CI：如果您需要管理复杂的多项目流水线，在 Kubernetes 上运行自己的 runner 基础设施，并且更倾向于使用由单一供应商管理安全扫描和容器镜像库的统一平台。
常见问题
我可以在 GitHub 代码库中使用 GitLab CI 吗？
可以。GitLab 支持针对外部代码库的 CI/CD。这允许您在 GitHub 托管的代码上运行 GitLab CI 流水线，不过与使用原生的 GitHub Actions 相比，这需要额外的配置。
哪个平台对构建依赖项有更好的缓存机制？
两个平台都提供了强大的缓存机制。对于复杂的多分支策略，GitLab CI 的缓存键配置通常更加灵活；而 GitHub Actions 则严重依赖社区维护的缓存 action。
CI 分钟数的计费模式对比如何？
两个平台都提供包含托管 runner 分钟数的免费层。GitLab 在所有方案中都根据计算资源的使用情况进行收费，而 GitHub Actions 的定价则根据代码库的可见性以及 runner 的操作系统而有所不同。