持续集成#

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 三元组文件。

与其从文件和文件夹的角度思考 Arrow CI，不如从概念上将其划分为两个主要类别

动作触发构建：根据 GitHub 上的特定动作（打开拉取请求、合并拉取请求等）触发的 CI 作业
扩展构建：手动触发，其中许多在夜间运行

动作触发构建#

.yml 文件在 .github/workflows 中，这些文件是 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 服务上运行任务以及使用哪个模板文件作为该任务的基础的信息。