持续集成

Arrow 的持续集成相当复杂，因为它需要在不同的包管理器、编译器、多个软件库版本、操作系统以及其他潜在的变化源组合上运行。在本文中，我们将概述其主要组件以及相关文件和目录。

Arrow CI 的一些核心文件是：

• docker-compose.yml - 在这里我们定义 Docker 服务，这些服务可以使用环境变量或这些变量的默认值进行配置。

• .env - 在这里我们定义默认值来配置 docker-compose.yml 中的服务。

• appveyor.yml - 在这里我们定义在 Appveyor 上运行的工作流。

我们使用Docker来实现可移植和可重现的 Linux 构建，以及在 Windows 容器中运行 Windows 构建。我们使用Archery和Crossbow来帮助协调各种 CI 任务。

需要注意的一点是，docker-compose.yml 中定义的一些服务是相互依赖的。在本地运行服务时，您必须首先手动构建其依赖项，或者通过使用 archery docker run ... 来构建它，后者会自动查找并构建依赖项。

Arrow 项目中有许多与 CI 相关的重要目录：

• .github/workflows - 通过 GitHub Actions 运行的工作流，由诸如拉取请求提交或合并等事件触发。

• dev/tasks - 包含通过 archery crossbow submit ... 触发/提交的扩展作业，通常是夜间构建或与发布过程相关的作业。

• ci/ - 包含脚本、Dockerfiles 和任何补充文件，例如补丁文件、conda 环境文件、vcpkg 三元组文件。

与其从文件和文件夹的角度来思考 Arrow CI，不如将其概念性地分为两大类：

• 动作触发构建：基于 GitHub 上的特定动作（拉取请求打开、拉取请求合并等）触发的 CI 作业。

• 扩展构建：手动触发，许多是夜间运行的。

动作触发构建

.github/workflows 目录中的 .yml 文件是针对特定动作在 GitHub 上运行的工作流。该目录中的大多数工作流都是 Arrow 特定实现的，并且在修改了与该语言实现相关的代码时运行，但其他值得注意的工作流包括：

• archery.yml - 如果对 Archery 工具或其运行的任务进行了更改，此工作流将运行必要的验证检查。

• comment_bot.yml - 通过监听 GitHub 拉取请求评论中的以下字符串来触发某些操作：

  • @github-actions crossbow submit ... - 运行指定的 Crossbow 命令。

  • @github-actions rebase - 将 PR rebase 到主分支。

• dev.yml - 每当 PR 有活动或 PR 合并时运行；它运行 linter 并测试 PR 是否可以合并。

• dev_pr.yml - 每当 PR 打开或更新时运行；检查 PR 标题的格式，如果需要，将指派人添加到适当的 GitHub issue（或添加评论要求用户在标题中包含 issue ID），并添加任何相关的 GitHub 标签。

还有另外两个文件定义了动作触发构建：

• appveyor.yml - 运行与 Python 或 C++ 相关的提交。

扩展构建

Crossbow 是 Archery 的一个子组件，可用于手动触发构建。可以在 Crossbow 上运行的任务可以在 dev/tasks 目录中找到。该目录包含：

• 文件 dev/tasks/tasks.yml，其中包含可以通过 Crossbow 运行的各种任务的配置。

• 包含不同任务模板（使用jinja2 语法指定）的子目录，大致按语言或包管理系统划分。

这些任务中的大多数作为夜间构建的一部分运行，但也可以通过向 PR 添加以 @github-actions crossbow submit 开头，后跟要运行的任务名称的评论来手动触发。

为了方便起见，dev/tasks/tasks.yml 中的任务是按组定义的，这使得可以一次向 Crossbow 提交多个任务。这里的任务定义包含关于要运行 docker-compose.yml 中定义的哪个服务、运行任务的 CI 服务以及用作该任务基础的模板文件的信息。