持续集成#

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，不如从概念上将其分为 2 个主要类别

  • action-triggered builds：基于 GitHub 上的特定操作（打开拉取请求、合并拉取请求等）触发的 CI 作业

  • extended builds：手动触发，许多按夜间运行

Action-triggered builds#

.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 标签

还有两个其他文件定义了 action-triggered builds

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

Extended builds#

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

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

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

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

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