持续集成

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/ - 包含脚本、dockerfile 和任何补充文件，例如补丁文件、conda 环境文件、vcpkg triplet 文件。

与其根据文件和文件夹来理解 Arrow CI，不如将其概念性地划分为两个主要类别：

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

• **扩展构建**: 手动触发，许多在夜间运行

动作触发构建

.github/workflows 中的 .yml 文件是在 GitHub 上响应特定操作而运行的工作流。此目录中的大多数工作流是 Arrow 实现特定的，并在进行影响该语言实现相关代码的更改时运行，但其他值得注意的工作流是

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

• comment_bot.yml - 通过侦听 github 拉取请求注释中的以下字符串来触发某些操作

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

  • @github-actions autotune - 运行许多样式/格式化程序，构建一些文档，并提交结果

  • @github-actions rebase - 将 PR 变基到主分支上

• dev.yml - 在 PR 上有任何活动或 PR 被合并时运行；它运行 linter 并测试 PR 是否可以合并

• dev_pr.yml - 在 PR 打开或更新时运行；检查 PR 标题的格式，如果需要，将受让人添加到相应的 GitHub 问题（或添加注释请求用户在标题中包含问题 ID），并添加任何相关的 GitHub 标签

还有两个其他文件定义了动作触发构建

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

扩展构建

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

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

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

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

为了方便起见，dev/tasks/tasks.yml 中的任务按组定义，这使得可以更轻松地将多个任务一次性提交给 Crossbow。此处的任务定义包含有关运行 docker-compose.yml 中定义的哪个服务、运行任务的 CI 服务以及使用哪个模板文件作为该任务基础的信息。